[Scons-users] Dependencies, preprocessed header files, et al

[Tom Tanner (BLOOMBERG/ LONDON)]

Would this work for you?

obfuscate (or copy) .c to .c.c
compile .c.c to .c.o
and carry on more or less as normal?

If you happen to have a compiler that doesn't care too much about the extension, you could also

obfuscate (or copy) .c to .cf
compile .cf to .o

That'd probably be easier, but the first one should still be possible, as long as you remember to copy if you aren't obfuscating.



----- Original Message -----
From: scons-users at scons.org
To: scons-users at scons.org
At: May 29 2013 14:44:25

  
In the C solution I have, almost the entirety of the source code and header files are preprocessed with an obfuscator before they are compiled (at least in certain variant builds).

The previous build approach is imperative so performs this step first and then performs the rest of the build pretty much as before, but now pointing at the directory in which the obfuscated source lives. Effectively header paths and source paths are remapped to the new location.

Now I'm moving to SCons I'd like to have a SConscript sub build file which can be used either on the original unobfuscated source or on the obfuscated source preferably such that it doesn't need to know if it's compiling and just the thing that drives it knows any better.

i.e. something like:

SConscript.thing
     env.StaticLibrary(
        'thing',
            Glob('src/stuff/*.c') + Glob('src/morestuff/*.c'),
        CPPPATH = ['include/stuff', 'include/morestuff', 'include/publicapi']
       )

I'm invoking this somewhere up above leveraging the variant system.

SConstruct
 SConscript( 'SConscript.thing', variant_dir='unobfuscated', src='.', duplicate=0, exports={'env':env} )

I was sort of hoping I could use that "src" argument to remap the lower level script to my new directory, like so:

SConstruct
        # SCons steps here to obfuscate source to a new directory, using a builder.
   # obfuscated_root points to some directory in the output area where the obfuscated source was generated
  SConscript( 'SConscript.thing', variant_dir='obfuscated', src=obfuscated_root, duplicate=0, exports={'env':env} )

But from what I've understood from looking around and trying various arguments this is not really (i) possible, or (ii) a good idea.

An alternative strategy I tried was to pass down the path to the new files and prefix it as necessary. I don't really like this as it seems prone to error (as it needs to be manually added) and also the dependencies aren't tying up:

SConstruct
  SConscript( 'SConscript.thing', variant_dir='obfuscated', src='.', duplicate=0, exports={'env':env, 'subpath', 'obfuscated_root/'} )

SConscript.thing
   Import('env','subpath')
  env.StaticLibrary(
      'thing',
          Glob(subpath + 'src/stuff/*.c') + Glob(subpath + 'src/morestuff/*.c'),
        CPPPATH = [subpath + 'include/stuff', subpath + 'include/morestuff', subpath + 'include/publicapi']
          )

This somewhat worked, but with a fair few limitations (build order specifically) and specifically the problem was that the header dependencies simply didn't work. From what I've read/understood around the area of code generation this is because at the point at which I prepare the task to compile all these source files there is no file to scan for dependencies (because it won't be created until after the obfuscation task is run).

I'm safely outside my comfort zone now and so I thought now might be the time to request any wisdom on what I'm doing and perhaps how I should be doing it (or if anyone else has accomplished anything similar).

A fallback scenario might be either to have a separate scons script to handle the obfuscation step and then just make a copy of my SCons build files into that obfuscated root and initiate another SCons build from there (although I'd rather not have to). The advantage of this would be that at least the sub build script is the same (and simple) in both cases.

The actual solution is predictably much larger than just a few files, so I really want to avoid adding lots of manual steps.

If it comes to it, and there's nothing else to be done I could live with a solution where if any header files is changed (and thus needs to be re-obfuscated) that all source files needed to be rebuilt. The obfuscation steps take far, far, far longer than the compilation steps.

Any suggestions or advise would be much appreciated (although if you start talking about scanners or emitters... go slow for me),
Mark


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 10159114690456002.txt
Type: application/octet-stream
Size: 149 bytes
Desc: not available
Url : http://four.pairlist.net/pipermail/scons-users/attachments/20130529/067562a2/attachment.obj