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

[Scott Davies]

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/f5f3c068/attachment.htm