[Scons-users] Library configuration

[Daniel Russel]

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"


On Wed, Jun 20, 2012 at 1:17 PM, John Pye <john.pye at anu.edu.au> wrote:


> Hi all

>

> FWIW I have not found uniformity in the way that autotools links to

> different shared/shatic libraries, nor have I found uniformity in the

> commands required to force autotools to *build* static vs shared libraries.

> There might be some conventions, but they're not universal. SCons provides

> the means to generate sane command-line user's documentation ('scons -h')

> which you always need to check with ./configure, equally.

>

> The shortcoming here that I see is that SCons is not very good at figuring

> out if what your system provides is a static library, or a shared library,

> and linking to the correct version (or allowing the user to choose, in the

> case that both are there). Attempting to do this stuff and simultaneously

> support multiple compilers probably makes things almost impossible (C++ ABI

> incompatibilities, etc etc).

>

> I suggest that a solution to this should be done specific with

> dependency-specific flags and/or env vars, since in a large project, one

> doesn't want to link every output file to any given library, it will be

> something that internally you want to retain control over. So I suggest

> something like

>

> scons GSL_LIB=gsl GSL_LIBPATH=/usr/lib GSL_INCLUDE=/usr/include/gsl-**1.11

>

> or

>

> scons GSL_STATIC=/usr/lib/libgsl1-**11.a GSL_INCLUDE=/usr/include/gsl-**

> 1.11

>

> also, nice to have

>

> scons GSL_PREFIX=~/my-gsl

>

> We use something similar to this approach with ASCEND, although it's

> fairly messy/wordy, and we don't support non-GCC compilers.

>

> Cheers

> JP

>

>

> On 20/06/12 11:37, Guillaume Turri wrote:

>

>> Hi,

>>

>> 2012/6/20 Evan Driscoll<driscoll at cs.wisc.edu>**:

>>

>>> On 06/20/2012 12:51 AM, Brady Johnson wrote:

>>> (2) it would hopefully give some uniformity in how those features are

>>> accessed.

>>>

>>> And while I'm at it, I might as well ask now: does this feature sound (a)

>>> awesome, (b) meh, (c) stupid?

>>>

>> To me, it could be awesome to have a standard way to let the end user

>> add options like --with-myLib=xxx, or flags such as LDFLAGS and so on

>> (à la autotools!)

>>

>> I really like scons, and this lack of uniformity is the only thing

>> that prevent me from using it more than I currently do.

>> Fixing it could remove that fear that an end user tells me "Hey, I've

>> this special config, and I know that with autotools I just have to set

>> this flag, but since you use scons I don't know how you handle it

>> without reading your Sconscripts".

>>

>> Regards,

>> Guillaume

>> ______________________________**_________________

>> Scons-users mailing list

>> Scons-users at scons.org

>> http://four.pairlist.net/**mailman/listinfo/scons-users<http://four.pairlist.net/mailman/listinfo/scons-users>

>>

>

> ______________________________**_________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/**mailman/listinfo/scons-users<http://four.pairlist.net/mailman/listinfo/scons-users>

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://four.pairlist.net/pipermail/scons-users/attachments/20120620/c79c56b9/attachment-0001.html>