[Scons-users] Library configuration

Evan Driscoll driscoll at cs.wisc.edu
Wed Jun 20 21:12:52 EDT 2012


On Wednesday, June 20, 2012 05:59:07 PM Daniel Russel wrote:

> We went with just having flags "includepath", "libpath" in which the users

> put all the places to have the compiler look for includes/libs separated by

> ":"s. I'm personally not a big fan of specifying the includepath/libpath

> for each library as it is

> - misleading as the compilation will end up being like "gcc

> -I/path/to/a/include -I/path/to/b/include" so all headers are searched for

> in all places and having a big directory that includes several packages is

> not unusual

> - the order of search is unspecified (sometimes you have multiple versions

> around and you want to make sure one is found instead of the other)

> - and verbose:

> includepath="/path/to/a/include:/path/to/b/include"

> vs

> A_include="/path/to/a/include" B_include="/path/to/b/include"


To play devil's advocate for a moment for a moment:

1) If your script follows the usual autoconf convention of looking at CFLAGS,
LDFLAGS, etc., then your way can be emulated:
CPPFLAGS="-I/path/to/a/include -I/path/to/b/include"
instead of
includepath="/path/to/a/include:/path/to/b/include"

This is something I want to do anyway, regardless of other mechanisms.

2) If you are building multiple projects, perhaps not all of them will need to
use the same libraries; separating the libraries means that your
executable 1 can include and link libraries A and B, but your executable 2
can include and link just B.

Though I'm not sure how important (2) is in practice. And it seems like you'd
need multiple configure contexts to take advantage of it... though that seems
very possible. And I do like your reasons. Might also obviate some coding.
Hmmm.

Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://four.pairlist.net/pipermail/scons-users/attachments/20120620/43fb4f0d/attachment.htm>


More information about the Scons-users mailing list