[Scons-users] Change order of parameters in linker call

William Blevins wblevins001 at gmail.com
Wed Aug 5 17:10:10 EDT 2015


On Wed, Aug 5, 2015 at 4:31 PM, Dominic Binks <dominic.binks at thebinkles.net>
wrote:

> Bill
>
> On 05/08/2015 20:17, Bill Deegan wrote:
>
>> Dominic,
>>
>> As one who's asked users to read the documentation, I always (pretty
>> sure here) point to the section in the Users Guide and/or manpage.  And
>> occasionally (If I'm not answering from my mobile device and have some
>> time to do so) copy/paste the most relevant snippet of info into the
>> email.
>>
>
> Yes you do and I've seen that.  But I've also seen other responses.
>
>
>> The variables you've listed are in the manpage.  There's a long list of
>> variables all together with a description of their function there.
>> This is fairly typical manpage structure.
>>
>
> Yes they are there but I disagree about man page layout.  I just looked up
> bash (http://linux.die.net/man/1/bash) and History Expansion/HISTORY
> EXPANSION - there embedded in the section about how to use history
> expansion are references to the behaviour of certain variables that adjust
> how history expansion works.  And other sections e.g. the description of
> what [[ expression ]] does references the CONDITIONAL EXPRESSIONS section
> of the man page.  In my experience I think the bash man page is fairly
> typical.  Maybe we've just used different systems.
>
>
>> If we listed all the variables which could influence the behavior of
>> each and every builder/command which goes in a SConstruct/SConscript, it
>> would be a lot more verbose and (likely) harder to search. manpages are
>> typically not hyperlinked so you would have to search for CPPPATH (for
>> example) many many times before you would find the substantive
>> information.
>>
>
> I don't think that's the case.  In some cases the variables have a prefix
> which perhaps could be referenced by the builder.  I believe you're right
> searching could be a pain if done in one hit but with two searches - one to
> the variables definition section and then another to variable in question
> it would be more accesible.
>
> For example:
>
>  Program() , env.Program()
>
>     Builds an executable given one or more object files or C, C++, D, or
> Fortran source files. If any C, C++, D or Fortran source files are
> specified, then they will be automatically compiled to object files using
> the Object builder method; see that builder method's description for a list
> of legal source file suffixes and how they are interpreted. The target
> executable file prefix (specified by the $PROGPREFIX construction variable;
> nothing by default) and suffix (specified by the $PROGSUFFIX construction
> variable; by default, .exe on Windows systems, nothing on POSIX systems)
> are automatically added to the target if not already present. Example:
>
>     env.Program(target = 'foo', source = ['foo.o', 'bar.c', 'baz.f'])
>
>     VARIABLES: LIBS, LIBPATH, CC, PROGPREFIX, PROGSUFFIX
>
> (In fact just there in producing single line addition  I had to spend a
> couple of moments trying find out what the variable was that controlled the
> suffix of the executable - why isn't it EXESUFFIX for example? Because it
> isn't but how easy is it to discover this?)
>
>
>> In your specific case, we generally advise people to use LINKPATH and
>> LIBS as for 80-90% of the builds those are sufficient for setting the
>> linker command line flags.
>>
>>
> OK - that's reasonable enough except LINKPATH isn't referenced in the man
> page or the User's Guide.
>
> I assume you mean LIBPATH.  That might explain not finding it.


> I always advise new SCons users to read the whole manpage and the whole
>> users guide.
>>
>
> I believe I've read through both several times and scanned them many many
> times.  I consult them every time I need to do something and only sometimes
> find the answer.
>
>
>> Jumping in and trying to use SCons may work fine for you, but if you run
>> into a problem, you may need to read both those docs to get the
>> subtleties.
>>
>>
> Well I was left with little choice, I inherited a project which used SCons
> and as it needed changes making I had little choice but to dive in.  I
> absolutely believe the build system is vitally important and I want a build
> system that's as clean and tidy and logical as we try to write the code
> we're building.  I've argued and will continue to argue that build systems
> are so important to project success that they deserve time allocated to the
> build system as part of a project plan; I despair of the notion that the
> build system just works and we'll fix it when it breaks.  To that end I've
> completely rewritten build systems for projects to resolve the inherent
> weaknesses in them in my own time because I care about them.
>
> I've debugged race conditions in build systems that have involved
> constructing elaborate tests to validate my fixes do really fix the
> problem.  In one case I had to make over 3000 builds to provide enough
> evidence to Google that there was a serious intermittent bug in Java
> leading to random build breakage.  I don't treat build systems lightly - I
> want to extract the most value I can from them.
>
> Personally I just don't find the SCons documentation that helpful when
> solving questions like: how do I write a simple tool to invoke a command?
> how do I build a zip file where the build path is stripped out from the
> path names (this was added but was not available when I needed it)?  Or how
> do I create a build where I have a whole bunch of options which can be
> supplied to a command depending on needs but should be omitted if they are
> not needed?  Or how do I take a tarfile, untar it into the build output
> directory, locate the configure script, run the configure script with a
> bunch of settings that are pertinent to my specific build, build it (with
> make) and then install it into a location in the build directory so that I
> can later pick the built objects to reference in my other code?  Or have
> have some shared sources between host and target systems and some
> independent ones and build the whole lot in but build target objects into
> one location and sources into another without having to have two complete
> passes over the SConscripts?
>
>
The User's Guide is supposed to be a more detailed (user oriented) version
of an API document (IE. JavaDoc or Doxygen) output.  I think if the User
Guide included all these things it would be huge and everyone would cry for
a TL;DR version.  It's already rather large.

If a feature is simply not fully documented, then all user's reserve to
right to submit pull requests to update them.


> These are all issues that I have had to face in just doing my job and not
> found information in the documentation to answer the questions.
> Interestingly enough the distinction between Nodes, Files and Dirs (an
> early chapter in the user's manual) has rarely even raised it's head. I've
> had the occasional Dir looked up as File error but the problems I've faced
> when using SCons are much more to do with discovering where something has
> gone wrong and trying (it seems largely unsuccessfully) to make any sense
> of VariantDir in anything more than the most obvious use.  For example this
> blog: http://blog.bfitz.us/?p=1714 I've found to be more helpful than a
> lot of the documentation on the SCons.
>
> I'm sorry if I sound negative, but I have not found SCons that easy to use
> and one major reason is that the documentation lacks the level of detail I
> have needed to make progress.
>
> Of course it's possible that I'm just really really stupid and that SCons
> is really simple to use and I'm just doing it all wrong.  It wouldn't be
> the first time.
>
> Hope that helps!
>> -Bill
>>
>>
>> On Wed, Aug 5, 2015 at 12:06 PM, Dominic Binks
>> <dominic.binks at thebinkles.net <mailto:dominic.binks at thebinkles.net>>
>> wrote:
>>
>>     Ah, I see the confusion here and I retract my statement that it's a
>> bug.
>>
>>     But there is still some confusion here which I think the
>>     documentation needs to clear up.
>>
>>     Conventionally make uses LDFLAGS to specify flags to the linker
>>     using LIBS to specify the library depenencies.
>>
>>     I think the confusion comes from SCons introducing the variable
>>     LINKFLAGS in place of LDFLAGS.  I assume this change is due to
>>     Microsoft's linker being called "link" while Unix linkers are
>>     usually "ld" though there is an inconsistency here as SCons follows
>>     make in the use of CC/CFLAGS/CXXFLAGS etc.
>>
>>     However, as a user, when trying to discover how to control a link
>>     I'd look for three things in the SCons documentation:
>>     SharedLibrary() if I was building a shared library, Program() if I
>>     was building a program and Link() for linking something else (e.g.
>>     building a relocatable combined object file).
>>
>>     If I look up Program() or SharedLibrary() I find no reference to
>>     LIBS and LIBPATH, or indeed any of the other environment variables
>>     that would affect this operation.  If I look up Link(), I won't find
>>     it since SCons doesn't support this notion.  Ok so for linking guess
>>     at LIBS and LIBPATH would be reasonably obvious but it's not nearly
>>     so obvious when trying to do other things.  It would be enormously
>>     helpful if for each builder described there was a list of the
>>     environment variables that affect its operation as part of it's
>>     description.  It doesn't need to explain them, just reference them
>>     and even if it only had some of the more key and frequently used
>>     ones it would be a start.
>>
>>     I have run into this issue time and again: the documentation doesn't
>>     really support discovery of new things that SCons can do.  In the
>>     end I often end up scanning the Tools directory and reading the code
>>     and trying to figure out SCons is doing to understand what I need to
>> do.
>>
>>     Having watched this list for quite a while, I've seen a number of
>>     cases where questioners have been told rather curtly to read the
>>     documentation.  Maybe this is the reason the questioners have come
>>     to the list; that they have struggled to find the information they
>>     seek in the documentation due to the way it's presented.
>>
>>     Dominic
>>
>>
>>
>>     On 05/08/2015 19:32, Dirk Bächle wrote:
>>
>>         Hi Viktor,
>>         hi Dominic,
>>
>>         please, as others have already requested, provide an example
>>         showing how
>>         you call the Program Builder. Ideally, it would be a
>>         self-contained MWE
>>         in the form of an archive (SConstruct + sources, as *.TGZ for
>>         example)
>>         which demonstrates the problem that you experience.
>>
>>         @Dominic: The original post doesn't mention start-group/end-group
>> at
>>         all, so I don't understand why you refer to the according
>>         passage in the
>>         GCC specs when claiming that it's a bug indeed.
>>
>>         @Viktor: The default definition of the LINKCOM variable is
>>
>>             $LINK -o $TARGET $LINKFLAGS $__RPATH $SOURCES $_LIBDIRFLAGS
>>         $_LIBFLAGS
>>
>>         , so the question has to be raised how you get the source
>>         "test.o" to
>>         appear last in your command line. Are you sure that you're *not*
>>         simply
>>         adding the required "-L... -l..." flags to LINKFLAGS directly,
>>         but are
>>         using LIBS and LIBPATH as you're supposed to do (see also the
>>         UserGuide,
>>         Appendix A "Construction Variables")?
>>
>>         Best regards,
>>
>>         Dirk
>>
>>         On 05.08.2015 16:40, Viktor Dick wrote:
>>
>>
>>             Hi,
>>             I just now noticed that on ubuntu 14.04, the linker seems to
>>             have
>>             problems with the way it is called by scons. In particular,
>>
>>             g++ -o test test.o -L/usr/lib/x86_64-linux-gnu -lboost_system
>>
>>             works while
>>
>>             g++ -o test -L /usr/lib/x86_64-linux-gnu -lboost_system test.o
>>
>>             throws linker errors. Unfortunately, the second way is the
>>             one that is
>>             chosen by SCons by default when using the Program() builder.
>>
>>             Is there a quick fix to tell scons to change the order of
>>             the parameters
>>             or do I have to write a complete builder for this?
>>
>>             Regards,
>>             Viktor
>>
>>
>>         _______________________________________________
>>         Scons-users mailing list
>>         Scons-users at scons.org <mailto:Scons-users at scons.org>
>>         https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>     _______________________________________________
>>     Scons-users mailing list
>>     Scons-users at scons.org <mailto:Scons-users at scons.org>
>>     https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20150805/c97ee0ae/attachment-0001.html>


More information about the Scons-users mailing list