[Scons-users] Code generation and VariantDir?

[Dirk Bächle]

On 29.04.2014 00:10, Jason Fritz wrote:

> On Mon, Apr 28, 2014 at 3:42 PM, Dirk Bächle <tshortik at gmx.de 

> <mailto:tshortik at gmx.de>> wrote:

>

>     [...]

>

>

> This legacy build system is kind of messy, as I'm sure you can 

> imagine.  For example, one directory I've converted has a CPPPATH with 

> 60 different entries.  Each entry in CPPPATH is relative to the root 

> dir, e.g. "#/src/autogen".

>

That's a bad idea in general, you want the single SConscripts and their 
subfolders to be independent of their parents and relocatable as much as 
possible. This ensures that you're not running into any trouble, even 
when using variant dirs...and possibly combining them with "-j".
Cleaning up your build a little will definitely pay off in the long run.


> I think what you're saying is that any paths in CPPPATH that are 

> relative from the SConscript dir will be expanded to include the 

> output dir.  Is that correct?  E.g. "../autogen" would become 

> "release/src/autogen"

>

Correct, that's how it is supposed to work.


> I like the idea of a clear separation between inputs/outputs, but I'm 

> not sure yet if that's a good enough goal to make this change.  My 

> existing script is putting the .h files into the source dir, I just 

> need to find some way to get rid of the "Multiple ways to build the 

> same target" error.

>

> What did you think of my idea of having two hierarchies of SConscript 

> files?  SConscript_autogen would be used first without any 

> VariantDir/variant_dir option, then the normal SConscript hierarchy 

> would be used with VariantDir.

>

That would probably work (just like "duplicate=1", by the way). However, 
the approach above will even work if the contents of your header file 
(or any other file you auto-generate during the build) depend on the 
current environment. Depending on an environment variable or define, you 
might have to include additional headers or not...so you actually need 
two versions of your "*.h" file.
So, by starting with a setup that might look a little over-engineered at 
first, you're pretty safe against changes and have a scalable build. And 
the costs for this aren't that high, I think.

Just my 2 cents.

Regards,

Dirk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20140429/b0e17b06/attachment.htm