Custom Query (122 matches)


Show under each result:

Results (94 - 96 of 122)

Ticket Resolution Summary Owner Reporter
#94 worksforme support cl version 16 stefan stefan

Ted reports, that building with MS compiler version 16 does not work anymore, because the deprecated -o option has finally been removed.

One may patch libtool to use -Fo and co. instead.

#95 fixed upgrade to newer autotools version stefan stefan

It would be nice to update to a more recent autotools version, which may also fix some open issues.

Lou's thoughts:

	I vote to upgrade. Painful but waaaay overdue. Exotic environments
aside, hanging on to these ancient autotools versions is an ongoing
annoyance on mainstream flavors of unix.

	Tactics and time are serious issues. This is not something to rush
into, and it will take a while to complete. If we really want to take
advantage of the progress in autotools, we need to strip all of our
PROG_CXX, etc.) and start clean. Then we'll need to find people willing
to test on the various exotic platforms that are represented in coin.m4
to see which tweaks need to be reinstated.

	We should give serious thought to the set of platforms we're willing to
continue to support. Much as it pains me to say it, Solaris is one of
the ones that deserves that thought. It's clear that Oracle cares only
about the server market as a vehicle to sell oracle products. Solaris on
the desktop seems to be abandoned.
#96 migrated doxygen documentation links to absolute paths stefan stefan

The new doxygen documentation that uses tag files to connect the documentation of different projects seem to produce absolute paths, which are bad when copying the docu to the webserver.

E.g., the link for OsiClpSolverInterface at points to

It's not clear yet if this is a build system issue or a problem with the scripts that automatically generate and copy the documentation, or both.

Some comments from Lou:

What happens at present is that doxygen documentation is built in the build directory. For classic package Foo, with externals Ext1, Ext2, documentation is built in

  ${build}/Ext2/doxydoc/html        <-- external's doxydoc directory
  ${build}/doxydoc/html             <-- package doxydoc directory

Installation installs only the package doxydoc/html directory into ${install}/share/coin/doc/Foo/doxydoc/html. This works well for the split configuration but is arguably wrong for the classic package, because the installed doxydoc will reach back to the build directory for each external's doxydoc. But it's only a problem if the build directory disappears. I haven't worried too much about it on the theory that we're headed towards separate packages, which will replicate the split configuration.

The DOXYGEN configure macro produces absolute paths. This could possibly be fixed, but it'd be a bit painful.

The DOXYGEN configure macro looks for tag files first in the build directory, then in the install directory.

The advantage to this scheme is that source files of externals are processed exactly once (they are excluded in the package's doxygen.conf file, hence not processed a second time when the package doxydoc is built). A second advantage is that it works for the split configuration (packages checked out without externals, connected through the install directory).

It would be nice to running doxygen unless source actually changes, but the current directory structure makes that more or less impossible (would require enumerating source files at a higher level in the makefile hierarchy than is done at present).

From what Laci and Matt have said, the problem would most likely be that the absolute path to the build directory has changed between the old and new server, or the build directory is absent.

Note: See TracQuery for help on using queries.