[Scons-users] Custom builder with conditional actions

[jeremy combs]

I have come to a somewhat similar conclusion.  I also agree on not copying
over the .o files.  I was just describing the process.

My actual plan as of right now:
.c files generate .o files like normal
special builder that I pass the .o file that always generates a
something_*.o
    This file is either a straight copy or has the extra processing.
something_*.o files generate final binary.

Doing things this way seems somewhat ugly since the custom action is doing
a lot of things that would normally be wrapped up by SCons.  For example
launching another gcc process.  I have tried to construct my gcc command
line using the construction variables that SCons itself uses.  It seems
like I should be using SCons to do this, and I'm looking for a better way.
I honestly don't know if there is one.

I am looking for what is the "best" way to do this.

Thank you,

Jeremy

On Tue, May 19, 2015 at 1:58 PM Dirk Bächle <tshortik at gmx.de> wrote:

> Hi Jeremy,
>
> On 19.05.2015 17:03, jeremy combs wrote:
> > I am trying to create a builder that performs actions similar to how the
> Linux kernel does symbol versioning.
> > See (
> https://github.com/torvalds/linux/blob/c0a80c0c27e5e65b180a25e6c4c2f7ef9e386cd3/scripts/Makefile.build#L200
> )
> >
> > As a first step I am trying to duplicate the linux kernel's steps as
> close as I can:
> >
> > 1. Build .o file from .c file
> > 2. if .o file contains special section
> >          2.true.1.  Run:  gcc -E [.c file] | [analaysis program] >
> [.o.ver file]
> >          2.true.1   Run: ld -T [.o.ver file] -o [other.o file]
> >          2.true.1   Run: mv [other.o file] [.o file]
> >     2.false.1  Copy [.o file] [other.o file]
> >
> > [...]
> >
> > So after all that I guess my question is: What is the recommended way to
> do something like this where actions are dependent on
> > source file contents?
> >
>
> the way I see it, it's not your source files that drive the further
> processing but the .o files as your targets. That's why the
> classical approaches like an "action generator" won't work for you, you'd
> have to know the name of the resulting .o file beforehand.
>
> Since SCons relies on proper dependency information (as derived in the
> Emitter/Scanner) you're basically stuck: you can't get at the
> required information without actually building the .o file. This is the
> same problem as with Java files, you have to compile them
> first, to know which .class files get created additionally by
> anonymous/inner classes. But then it's too late to add this info to
> the dependency graph...files that would otherwise implicitly depend on
> these "new" nodes might already be marked as "up-to-date" and
> won't get rebuilt.
>
> Finally, overwriting your .o file "in place" ("mv [other.o file] [.o
> file]") is a bad idea in general.
>
> Just my 2 cents.
>
> Best regards,
>
> Dirk
>
> _______________________________________________
> 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/20150521/98e43843/attachment.html>