Dirk Reiners wrote: > Hi Allen, > > Allen Bierbaum wrote: > >> - 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. >> > > See other mail. > > >> - 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 know, it seems to be more trouble than benefit. Just calling the > build multiple times is very simple, and given that the only case where > I can see myself running multiple builds at the same time (i.e. > variants) is a dailybuild, where just calling multiple independent > builds works just as well I really don't see the case for variants. > Carsten wrote:
> 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). I see what you are both saying and I think there is a part of this that I was not clear about. There are two parts to variants. 1. Providing a single location to inform the build and any scons-addons options (boost, standard, etc) what "type" of build it is (debug/optimized/hybrid, ia32, x64, etc) 2. Make it possible for the build to have a "loop" in it that will build multiple variants at the same time. The second one ended up very difficult to do well and made the current build more complex then needed. That said though, 1 is still needed so we can tell everything in the build what it should be doing. For example, Carsten showed: scons type=optimized build_suffix=dbg64 compiler_options="-m64" But if you run this command, how does the boost option know how to do all the logic internally to select a library that can work against optimized and is compiled x64? This is the problem that is meant to be solved by part 1 above. Maybe I am making this more difficult then needed though. If you can find a way to get everything in the current build and in scons-addons all working together in a simpler way, then I am all for that. :) -Allen > My $.02 > > Dirk > > > ------------------------------------------------------------------------- > 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
