[Scons-users] [c++] Automatically choosing sources for linking

[Scott Davies]

One more thought about the feasibility of doing this:

If automatic link-time dependency determination takes too long (on top of
the header dependency determination), you can probably cache the link
dependencies and only bother regenerating them when an attempt to link an
executable fails.  In my experience, out-of-date link dependencies almost
always result in link-time errors. (As opposed to out-of-date header
dependencies, which very often result in fully compiled but profoundly
confused and crashy executables that I spend hours debugging and cursing at
before slapping my forehead, crying for a little bit, and then doing a
"make clean".  I understand all too well why you do *not* want to play
around with out-of-date *header* dependencies...link dependencies might be
safer to play fast and loose with, though.)

- Scott


On Fri, Mar 28, 2014 at 12:51 PM, Scott Davies <scottd at gmail.com> wrote:


> Hi Dirk --

>

> I know that SCons can handle the header dependencies. I'm interested in

> also automatically determining what object files need to be linked into

> what executables (of which I have many with very different sets of

> dependencies, because of unit tests) in order to come up with a generic

> build system that will work on all my projects without my having it to tell

> it anything manually (other than external library dependencies) or mess

> around with internally created libraries (which fundamentally handicap

> build systems by making dependencies more coarse-grained).

>

> Like in Viktor's project (if I understood him correctly) -- and I would

> argue, like in a *huge* fraction of C++ projects -- this is actually

> *theoretically* trivial in my project, because anything declared in foo.hpp

> is defined in foo.cpp (or in its trivially determined link dependencies) if

> foo.cpp exists.  All you need to do is compute a set of link-time

> dependencies from the compile-time dependencies, where you basically copy

> additional link-time dependencies from foo.cpp/o (if foo.cpp exists) to any

> .cpp/o that includes foo.hpp.

>

> I think a build system that could do this would be a godsend to the C/C++

> community, frankly, and have trouble believing that *all* of the major

> build systems I've looked at completely punt on this issue and force the

> user to do one of:

>

> (1) Manually list which .o files must be linked into what executables.

>  This is usually even more tedious than manually listing the compile-time

> dependencies!

>

> (2) Dump all the re-used object files into a single library and link all

> the executables against it, which (if they're static libraries, at least)

> require all executables to be recompiled every time any single object file

> changes even if those changes are irrelevant.  (Dynamically loaded

> libraries might partly fix that problem, I guess, but I generally find the

> run-time issues involved with dynamically loaded libraries so obnoxious

> that I tend to avoid them if at all possible.)

>

> (3) Manually cluster the .o files into a set of libraries (set size:

> greater than one).  This is basically a way of trading off between the

> problems inherent in (1) and the problems inherent in (2) depending on how

> much you hate doing tedious busywork vs. how much you hate twiddling your

> thumbs while your build system does tedious busywork.

>

> All three of these options are basically tantamount to admitting that your

> special-purpose dependency-tracking system can't actually properly track

> dependencies in C/C++ because of the header-vs-source divide.  (But hey,

> that's OK, because nobody else's does either!)

>

> If we could get automatic link-time dependency determination working in

> this not-so-special case and have it not be too much slower than automatic

> compile-time dependency determination, then I would argue that this is a

> (very rough) sketch of what about half of all SConstruct files for C/C++

> projects would look like, in their entirety:

>

>     externalLibraries = ["-lm", "-lssl", ...]

>

>     guessExecutables() # XXX.cpp has "int main(" or "void main(" implies

> XXX is executable

>

>     duh()

>

> where "duh" is, of course, an alias for

> "doTheBlindinglyObviousTransitiveDependencyPropagationThingWithTheObjectFilesAndExecutablesBecauseWeUseTheObviousSimpleCanonicalRelationshipBetweenHeaderAndSourceFiles".

>

> This would be HUGE.  *Everybody* would use SCons.

>

> Or am I missing something?

>

> Best wishes,

> -- Scott

>

>

>

>

>

>

>

>

>

> On Fri, Mar 28, 2014 at 1:17 AM, Dirk Bächle <tshortik at gmx.de> wrote:

>

>> Hi Scott,

>>

>>

>> On 28.03.2014 00:26, scottd wrote:

>>

>>> Did this ever make it to the wiki?  I was just looking at SCons (along

>>> with

>>> other build systems) and wondering if there was an easy way to do exactly

>>> this...very happy when I found an identical question answered just

>>> recently

>>> in the email archives.

>>>

>>> Having to manually list all the objects that have to go into each

>>> executable

>>> is pretty stupid when some huge fraction of C and C++ projects can have

>>> them

>>> computed from the automatically detected #includes with a tiny bit of "if

>>> foo.h is included, also include everything included by foo.c if it

>>> exists as

>>> a link-time dependency" hackery.  If I can do this easily with SCons,

>>> then I

>>> am definitely switching to SCons.

>>>

>>

>> please note that the normal detection of implicit dependencies, e.g.

>> Header files (*.h/*.hpp) for C++ projects, works "out-of-the-box" in SCons.

>>

>> Viktor puts special requirements on his build process, that's why some

>> hacking is necessary. If you follow standard C/C++ project setups, there

>> shouldn't be anything in your way. Just try SCons out on a very simple

>> project, maybe you have a few files/folders that are currently controlled

>> by make/autotools.

>> If you get stuck while rewriting stuff, please ask your questions right

>> here and let us help you out.

>>

>> Best regards,

>>

>> Dirk

>>

>>

>> _______________________________________________

>> Scons-users mailing list

>> Scons-users at scons.org

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

>>

>

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20140328/e5070fc1/attachment.htm