Re: [Opensg-core] Re: [Opensg-commits] cvs commit: OpenSG SConstruct

[Chad A. <ae...@vr...>]

Gerrit Voss wrote:
> On Sat, 2005-01-29 at 18:48, Chad Austin wrote:
>>Gerrit Voss wrote:
>>>Another important question is how easy can I manipulate the
>>>dependencies, sometimes during development I really want to disable
>>>either updating the dependencies or using them at all. Similar how
>>>easy can I remove a specific file (like OSGConfigured.h) from being
>>>used ? 
>>
>>You can't manipulate the dependencies.  SCons goes to great lengths to ensure 
>>correct builds.  ;)  (It sounds like your end goal isn't really to manipulate 
>>the dependencies...  what is it?)
> 
> 
> oh, I'm pretty sure I want exactly this ;-), but I admit it is a I know
> what I'm doing and the speed to rebuild dependencies sucks kind of 
> thing ;-). OSGConfigured.h is one example, given that it is written
> right now every time you call configure, don't know what SCons does, 
> so while I'm adding new options or a new packages I usually need to call
> configure quite some time until everything goes as I want it and
> rebuilding everything every time I do the test if it finally works
> is really not that good for my blood pressure ;-). Similar you fix or
> add some feature to one of the base files (e.g OSGBaseTypeTraits or the
> export define files) and rebuilding all just to see if the local fix
> works (you know it is local because you know what has triggered your
> action to look into it), at maximum beneficial for the coffee shop down
> stairs ;-). The trick is often I do not want to have a correctly build
> file, for example trying to solve unresolved symbol problems. If there
> are 42 unresolved symbols, all I care is if my fix gets it down to 41 
> or not and as this might need some time and trying I happily avoid
> rebuilding more than I really need. And I really do not want to call 
> 'rm this' 'make that' and probably 'make the_other_thing_too' all I want
> to call is 'make', ideally in the one build subdirectory I'm 
> interested in ;-). 

SCons simply won't let you break the dependencies.  So if you want to do just 
build a subset of object files to make sure they compile you (I know you said 
you don't want to do this ;) type "scons name_that_dir" and only stuff inside it 
will get compiled.  About OSGConfigured.h:  For local configuration changes, you 
do the same thing as above.  scons newoptions=values 
whatever_directory_you_are_testing  There is also an option '-u' which lets you 
run scons from a subdirectory and only builds stuff in that directory (and 
associated build dirs).  Maybe that would make life easier for you?

cd Some/Local/Dir/That/Broke
scons newoptions=1 -u

About unresolved symbols:  Not sure how you could do quick testing here without 
causing a rebuild of all source files that are out of date.  If you're modifying 
BaseTypeTraits to fix the unresolved symbols, it'll rebuild everything before 
linking.

> Again I admit tempering with the dependencies is like calling 
> memcpy(this, thats_what_i_want, sizeof(thats_what_i_want)); in one of
> your class constructor but still I'm doing it and I know that is 
> exactly what I want to do ;-))

Eep.  ^^  Too bad there's no way (that I know of) to 
assert(isPODType<ThisClass>);  ;)  I know what you mean, sometimes you just want 
to say "hey build! ignore everything else right now" but hopefully the 
advantages of scons' dependency model outweigh the disadvantages.  Personally, I 
love the fact that running with -j is sooo much faster, and there's no need to 
have a separate dependency pass.

>>>Last one, how easy can I change the compiler options for a single file
>>>without that triggering a complete rebuild ?, like switching from
>>>-c to -E does not seem to be that straight forward. (Straight forward
>>>means just replacing a single character ;-)).
>>
>>It would be possible to add some infrastructure to allow you to specify custom 
>>options on a per-file basis.  But why would you want to switch from -c to -E? 
>>As above, what's the use case?
> 
> 
> this is basic debugging, pretty often when the compiler complains 
> something is unknown or does not match or is double defined, one of
> the first things I do is walk  through the preprocessor output and check
> what might be wrong, combined with a good and convenient search function
> in your editor (e.g. emacs) this really helps ;-). This is really
> essential, and one of the main feature why I do not like IDE's at all,
> they do not allow me to do this easily ;-) Similar thing which gave me
> some fun lately, removing the default '/nologo' option on windows was
> not that straight forward for the scons based project I got. And I
> really needed it because the errors I got resulted IIRC from using
> mixing VS6 and VS.NET2003 tools, includes and libs. And the only way
> to figure this out was to look at the logos and see that the version
> numbers did not match. Again most of the people might not have this
> problem but I tend to have 3 or 4 Visual Studios plus a couple of Intel
> compilers on my machine so loosing control over options and which tools
> are chosen (this happens kind of magically behind my back) normally
> costs me some time ;-)

If you need preprocessor output, I use the -save-temps option to gcc.  I add an 
SCons build option called "saveTemps" and if you wrap it in $( and $) it doesn't 
affect the build signatures, so it doesn't cause spurious rebuilds.  So you 
could say "rm foo.obj; scons saveTemps=1 foo.obj" and then you'll have foo.ii 
and such.

Out of curiosity, how did you end up using different versions of Visual Studio 
from one SCons build?  That shouldn't happen by default (information is read 
from the registry, and the most recent version is chosen by default), so I'm 
curious.  :)

Cheers,
Chad