Re: persistent but local tweaks to a node's environment
Gabe Black <[email protected]>
| Newsgroups | gmane.comp.programming.tools.scons.user |
|---|---|
| Message-ID | <CABEwwBFvAk_beFFWZLES5wwsTvE-cN06wWrAqxg8xmFSvY+hXg@mail.gmail.com> |
Hi Gary, thanks for your response. You may have missed it in my email, but I describe that approach already, and explain why it doesn't/didn't work for me. I would like it to! I had hoped it would be that simple and straightforward, but getting it to work through SCons (rather than around SCons) has been quite tricky. Please let me know if I missed or misunderstood something in your email. Thanks! Gabe On Sat, Jul 24, 2021 at 7:25 AM Gary Oberbrunner <[email protected]> wrote: > I usually do something like > > Import('env') # might be opt or debug env > objs = [] > objs.append(env.Object('foo.cc', CCFLAGS='${CCFLAGS} -specialflag1')) > objs.append(env.Object('bar.cc')) > ... then later... > env.Program('prog.$PROGTYPE', objs) > > (Of course you can build objs any way you like; you could have a list of > sources and their extra flags and loop, or whatever you like -- it's just > python.) > > > On Sat, Jul 24, 2021 at 6:18 AM Gabe Black <[email protected]> wrote: > >> Hi! The project I work on builds several different versions of its >> outputs, like a debug version, an optimized version, etc. Also, some files >> in the project, for instance automatically generated files, need to have >> slightly customized build flags, like disabling certain warnings that are >> false positives and/or are in source we can't change. >> >> Right now we handle that by creating an environment for each build, which >> I think is the standard approach. Unfortunately, we then have to have a >> separate step which goes through and generates new environments based on >> those for each file that needs its slightly customized build flags. >> >> What I would *like* to do, is to be able to specify for any given node >> that it should build using the flags that would be implied by the >> environment that's pulling it in, except that they should be tweaked just a >> little bit. Something like: >> >> Object('foo.cc', '-Wno-deprecated-copy') >> >> and then: >> >> opt.Program('foo.opt', 'foo.cc', CCFLAGS='${CCFLAGS} -O3') >> debug.Program('foo.debug', 'foo.cc', CCFLAGS='${CCFLAGS} -g', >> OBJSUFFIX='.do') >> etc >> >> and then have foo.do build with "-Wno-deprecated-copy -g", and foo.o >> build with "-Wno-deprecated-copy -O3" >> >> The problem is, that as soon as I tell SCons to use custom variables, it >> Clone-s the underlying environment and disassociates from the underlying >> environment. >> >> One hacky solution I found was something like this: >> >> File('foo.cc').Tag('CCFLAGS', '-Wno-deprecated-copy') >> >> opt.Program('foo.opt', 'foo.cc', CCFLAGS='-O3 >> ${SOURCE[0].GetTag("CCFLAGS")') >> >> The problems with this are that, first, the CCFLAGS tag is not considered >> when checking if a target needs to be rebuilt, second that this requires >> accommodating each variable that can be extended explicitly, and third this >> is really not what that mechanism is for. >> >> Is there a solution to this, other than tracking things separately in the >> SConscript, and then at the end feeding things to SCons in the order we >> want? And generating custom environments as the cross product of build >> types and files that need tweaked build flags? >> >> Gabe >> _______________________________________________ >> Scons-users mailing list >> [email protected] >> https://pairlist4.pair.net/mailman/listinfo/scons-users >> > > > -- > Gary > _______________________________________________ > Scons-users mailing list > [email protected] > https://pairlist4.pair.net/mailman/listinfo/scons-users > _______________________________________________ Scons-users mailing list [email protected] https://pairlist4.pair.net/mailman/listinfo/scons-users