Hi Allen, Allen Bierbaum wrote: > Carsten Neumann wrote: > 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.
the idea was simply to get a bit closer to the well known configure; make; make install triple. RPMs have similar stages in their spec file, so I thought it might simplify writing spec files if our build is closer to what autotools based builds do. Anyway, this is probably not too important and doing things the "scons way" might avoid one or the other kludge ;) > - 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. I don't really see the need for something like variants, but maybe I'm missing something. What is the problem with typing scons type=debug build_suffix=dbg and scons type=optimized build_suffix=dbg64 compiler_options="-m64" jpeg_libdir=/usr/lib64 ... the first time and then later on to repeat/update the builds scons options_file=build.linux.dbg/options.cache and scons options_file=build.linux.dbg64/options.cache these calls can easily be put into a script that builds all sorts of variants over night and never is restricted to what a developer was willing to consider "a variant". (if the argument to options_file is a dir we could automatically look for a options.cache file in that dir to make the above lines even shorter). >> 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. In fact I wanted to forget about them and add the compiler_options option instead. Is the advantage of having extra options for these settings big enough to justify their complexity ? >> 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. The biggest problem I have is with understanding the BuildDir and Repository commands (their intended usage is explained here: http://www.scons.org/wiki/UsingBuildDir). The explanation in the wiki mentions three directories, but I can not map these to directories on my disk. Furthermore the whole concept of having files in the "work" tree shadow those in the "repository" tree seems horribly error prone to me. The behavior I want is this (this is basically what we always did, if something else is desired, now would be a good time to say so ;) ): - files created by fcd2code or flex/bison are put into the same directory as the input file (i.e. the .fcd) file in the Source/ tree. - .o files are put into the build dir, I don't really care if they all end up in one directory or if the Source/ tree structure is duplicated, although that is probably a nice thing to have. - lib*.so files are put into the build dir. installing puts everything into its proper location relative to the install_dir, as outlined in the wiki (https://opensg.vrsource.org/trac/wiki/Dev/PluginsPathes). Thanks for the input, 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
