[Scons-users] Custom builder with conditional actions

Bill Deegan bill at baddogconsulting.com
Thu May 21 09:26:54 EDT 2015


Jeremy,

Perhaps the best method would be to detect this in the source file before
you add it to SCons?
Then you could do something like this:

objects = []
for sf in sources:
    if check_source_for_directives(sf):
       normal_obj=env.SharedObject(sf)
       new_obj_file=sf.replace('.c','_mod.o')
       obj=env.Command(new_obj_file,normal_obj,'ld -T [.o.ver file] -o
[other.o file]')
    else:
       obj=env.SharedObject(sf)
    objects.append(obj)

...
use objects in your libraries/etc.

Since it's possible to determine the objects which need this special
treatment based on the sources, I'd sugguest that as the simpler method to
do so.

-Bill


On Thu, May 21, 2015 at 4:04 AM, jeremy combs <combs.jeremy at gmail.com>
wrote:

> Bill,
>
> The special section is caused by attributes on variables/functions in the
> c file.
>
> -Jeremy
>
> On Tue, May 19, 2015 at 7:16 PM Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
>>
>>
>> On Tuesday, May 19, 2015, jeremy combs <combs.jeremy at gmail.com> 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]
>>>
>>> I currently have this with a custom builder to take [.o file] to
>>> [other.o file] but in this custom builder I can't use SCons built in
>>> actions.  I have to build the gcc -E command line and execute it via
>>> subprocesses.  I would like to be able to use the builtin actions as much
>>> as possible to maintain compatibility.
>>>
>>> I have looked at Builders with a generator function, emitters and many
>>> examples.  Most of these examples run at evaluation time before the .o
>>> files are available to determine the needed actions.  It seems that every
>>> option that runs at build context (Scanners and Builders) when the .o files
>>> are available prevents me from altering the actions or tree at that time.
>>>
>>> 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?
>>>
>>>
>> What causes the .o file to have a special section?
>> The source file? Preprocessor flags? Othe command line flags during
>> compilation?
>>
>> -Bill
>> _______________________________________________
>> Scons-users mailing list
>> 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/20150521/37d23c52/attachment.html>


More information about the Scons-users mailing list