Carsten Neumann wrote:
> Hi,
>
> I'm trying to clean up the scons build a bit more, specific goals are
> reduction of hacks for option handling (msvs version, icc), separating
> build and install steps making them available as targets and removal of
> scons-addons variants.
>
>
Carsten: I am definitely interested in your effort. I know a lot of
the hacks I put in there are just that, hacks, and need fixed.
Hopefully you can see better solutions then I did. I am also very
interested in seeing how this could help make scons-addons more useful.
See comments below.
- Why separate build and install steps? One of the nice things about
the current system is that even a local "build" is a full install. I
guess if you really want an install step, it could be another "build"
that just triggers against a different target directory.
- removal of scons-addons variants. variants is an ugly hack to attempt
to solve a seemingly simple problem. I would be very interested in
doing more then just removing variants, but possibly going a step
further and coming up with what variants really should be and how to
make it useful for other people and other projects.
Conceptually variants is meant to be a way to say "I want to build
debug/optimized/hybrid and I want to build on ia32/amd64/IA64 and ...".
Then the options (boost, opensg, etc) can use these known settings to
link against the correct libraries, use the right options, etc.
Unfortunately the implementation got a bit ugly. Maybe you have some
ideas how to start from scratch and come up with something better.
> My plan right now is to have the following options (plus the existing
> ones for libs, features and what not):
>
> build_dir
> root output directory for the build
> default: build.<platform>
> build_dir_suffix
> if build_dir is *not* set, use this to append a suffix
> to the default build dir, i.e. this gives
> build_dir=build.<platform>.<suffix>
> install_dir
> root directory to install the system to
> default: ${build_dir}/install
>
> compiler
> type of compiler to use, i.e. one of "msvs", "gcc"/"g++",
> "icc"
> compiler_version
> version of compiler to use, only for "msvs" (one of "7.1", "8.0"
> or whatever versions work/are supported)
> compiler_executable
> executable name of the compiler (maybe only on linux, darwin)
> [my g++ is actually named g++-4.1 and without putting
> symlinks in /usr/bin my builds fail, this option should help]
> compiler_options
> additional options to pass to the compiler (I'm not sure about
> this one yet, scons-addons EnvironmentBuilder might be enough
> for now)
>
> variant
> choose between debug/optimized build
> selects a number of default options to the compiler, the
> value of compiler_options will be appended (i.e. it can be used
> to override the settings chosen by variant)
> This is basically a meta option to EnvironmentBuilder.
>
Don't forget hybrid and ABI options.
> option_file
> choose a file to read settings from
>
> For consistency reasons and to have them show up in the help message I'd
> like these options to be handled by scons-addons, which creates the
> problem of how to find the option.cache file to use. What I plan to do is:
>
> - if options_file is given, read that file then evaluate command line
> arguments. Write the settings used for the build to: options.cache.last
> and $build_dir/options.cache but do *not* change contents of options_file
>
> - if options_file is *not* given, use options.cache.last if present,
> otherwise use default settings and then evaluate command line arguments.
> Write settings to options.cache.last and $build_dir/option.cache
>
>
> Regarding the build/install steps and targets for each, I'm still a
> little unsure on how to do it. I'll probably end up installing the
> headers twice, in the build dir and then a second time in the install
> dir. Maybe someone using scons a bit longer has advice here, since I'm
> still trying to get used to the "scons build model", which either I do
> not fully understand or is only vaguely defined ;)
>
>
Let me know if I can be of any help.
-Allen
> Comments and further ideas very welcome,
>
> Carsten
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Opensg-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensg-core
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
