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

Dominic Binks dominic.binks at thebinkles.net
Wed Aug 5 16:31:06 EDT 2015


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 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?

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
>
>


More information about the Scons-users mailing list