[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