[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