[Scons-users] Help my build get faster... (was SCons and parts)

[Bill Deegan]

Re:
It's acceptable that scons take a few seconds on this mammoth project
but what really hurts is that when building something completely
unrelated (and that has no dependency on the mammoth project),  we
still have such a large startup time.
Now one solution would be completely disconnect the mammoth project
from the rest of the build. (I.E mv SConscript SConstruct)
Then I'd need to tell users that if they want to build something that
depends on the mammoth project then you need to first go to that
project and run scons there
and then come back and run the main scons build.
I'm still trying to avoid a solution like that because it adds more
required steps to our build, instead of just a simple scons command.

The simple solution would be to not include the SConscripts when the
mammoth project isn't going to be built. You can use command line flags
and/or Aliases for the user to use when calling SCons to indicate such.




On Wed, Aug 16, 2017 at 2:48 AM, Pico Geyer <picogeyer at gmail.com> wrote:

> On Wed, Aug 16, 2017 at 4:56 AM, Bill Deegan <bill at baddogconsulting.com>
> wrote:
> > Pico,
> >
> > You can do this.
> >
> > env.MyBuilder(Target,Source, ANY_ENV_FLAG=['a','b','c'],
> > CPPPATH=['z','d','f']
> > There's no need to clone the environment to have specialized flags for a
> > given builder or target..
>
> Bill,
>
> I think perhaps I didn't explain very well.
> I don't need many flags for a single builder. I need a *different set*
> of flags for each object.
> so perhaps as an example, something like this:
> stuff_to_build = {
> 'file1' : {opts = "-g -f", includes=['/path/to/include1',
> 'path/to/include2']},
> 'file2': { opts= "-g -h", includes=['/path/to/include3',
> 'path/to/include4']},
> ...
> 'file2000': {...}
> }
>
> And then the scons specific code would look like
> for k, f in stuff_to_build:
>    new_env = env.Clone()
>    new_env['opts'] = f['opts']
>    new_env['includes'] = f['includes']
>    t = new_env.MyCompiler(k)
>    all_targets.append(t)
>
>
> So each object would be compiled as
> mycompiler -o file1. out -g -f -I/path/to/include1 -I/path/to/include2
> file1
> mycompiler -o file2.out -g -h -I/path/to/include3 -I/path/to/include4 file2
> ...
>
> So I really do need a different env for each object, right?
> I know it may be a bit weird to have a different set of flags for each
> object file but this is the requirement for that project and not
> something that will change.
>
> It's acceptable that scons take a few seconds on this mammoth project
> but what really hurts is that when building something completely
> unrelated (and that has no dependency on the mammoth project),  we
> still have such a large startup time.
> Now one solution would be completely disconnect the mammoth project
> from the rest of the build. (I.E mv SConscript SConstruct)
> Then I'd need to tell users that if they want to build something that
> depends on the mammoth project then you need to first go to that
> project and run scons there
> and then come back and run the main scons build.
> I'm still trying to avoid a solution like that because it adds more
> required steps to our build, instead of just a simple scons command.
>
> Sorry for the long story but I hope that clears things up?
> _______________________________________________
> 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/20170816/dc6aff7f/attachment-0001.html>