Closed tkralphs closed 4 years ago
One may have several XYZ_BUILD within one project, in particular when several libraries are build, and it's important to get only the right XYZ_BUILD defined at the right places. Maybe it would be possible to just add -DXYZ_BUILD to XYZ_CFLAGS (again). One would need to try this. I don't remember whether there was an obstacle.
The automake manual suggests to add our -I
flags to AM_CPPFLAGS
. DEFAULT_INCLUDES
is set by autoconf to a useful value. I don't know what autoconf complains if you add to or reset DEFAULT_INCLUDES
, but it should be ok to just add to AM_CPPFLAGS
.
AM_CPPFLAGS
is the one that is shared among all libraries and programs within one Makefile.
For Cbc/src/Makefile, there are two libraries (libCbc and libCbcSolver) that need slightly different compiler flags (the XYZ_BUILD
) and so I put the flags into the library-specific libXyz_la_CPPFLAGS
.
Maybe cbc_generic_CPPFLAGS = $(CBCGENERIC_CFLAGS)
would work, too.
But in simpler cases, setting AM_CPPFLAGS
is preferable, I think.
automake tries to define libXyz_la_DEPENDENCIES
automatically if possible. I believe that it takes the conent of LIBADD or LDADD and picks the name of actual libraries from it and removes other linker flags. This works in easy cases where the libraries are known at time where automake is run. If variables are used in LIBADD or LDADD which value is only known after configure is run, then the libraries in these variables do not make it into the dependencies. This was a problem for the monolithic builds, because a change of, e.g., Clp, did not trigger a rebuild of Cbc, and so libXyz_la_DEPENDENCIES
was specified explicitly. But now that we build only against installed projects, it seems normal to only track dependencies within a project. If you install new version of the Clp library (without header changes), a make in Cbc will probably not trigger relinking of cbc anymore, but this wouldn't be expected behavior anymore. Though, with libtool and the dependencies tracking in the .la files, maybe there is some other magic happening.
Thanks for the thorough reply. It all makes sense, except for one thing. According to the documentation (and according to my own experience now with SYMPHONY), Ant specified _CPPFLAGS variable over-rides AM_CPPFLAGS (not adds to it). AM_CPPFLAGS are more like a default set rather than a base set. Since the libraries and the binaries all have _CPPFLAGS variables in the Cbc setup, it looks to me like AM_CPPFLAGS are always ignored.
OK, I'll have a look into Cbc in the next days.
I'll close this for now unless you want it as a reminder to look at Cbc.
f7285e1e6 adds -DXYZ_BUILD
into XYZ_CFLAGS
.
I have a few questions regarding the proper setup with the BuildTools master branch (the "new" build system).
XYZ_BUILD
now defined by manually adding a compiler flag inMakefile.am
instead of being added to the list of compiler flags automatically incoin.m4
as previously? The previous way seemed easier, but maybe just shifting the complexity out ofcoin.m4
?include
direectory, not insrc
. I used to add that extra directory toDEFAULT_INCLUDES
, butautoconf
now complains about this. I'm currently adding them toAM_CPPFLAGS
directly, but this is related to the next question.XyzLib_CFLAGS
and such) toAM_CPPFLAGS
or directly tolibXyz_la_CPPFLAGS
? There seems to be a mix of practices going on in Cbc. For example, we havebut then later, we have
Either way seems to work, but just want to have some canonical way of doing it across all projects that is uniform.
libXyz_la_DEPENDENCIES
, but now we aren't doing that anymore. Everything seems to work fine, but I just wanted to understand the change.I'm having some other issues with SYMPHONY, but I'm trying to work those out and then will post about it separately.