Gerrit Voss wrote: >Hi, > >On Thu, 2006-09-07 at 07:36 -0500, Allen Bierbaum wrote: > > >>Gerrit Voss wrote: >> >> >> >>>make it simpler, configure had a --with-suffix=xxx option >>>in order to create different build directories. Having the same is >>>better because this way I don't have to change scons if I need >>>another one. >>> >>> >>> >>> >>Ok. That should not be too bad. If may make managing your cached >>options a bit of a pain but I think we can probably come up with >>something to help out with that too. >> >> > >the simple solution from configure was : > >echo "#!/bin/sh" > $ac_gdz_commonbin/run_configure >grep '#' config.status | grep configure | grep '\-\-with' | sed -e >'s/# //g' >> $ac_gdz_commonbin/run_configure >chmod 755 $ac_gdz_commonbin/run_configure > >which simply wrote the last configure line to >Builds/<platform-spec>/bin/run_configure >This way rerunning configure the same way was dead simple. > >I don't know if scons allows something similar but that >would be enough for me (I guess I'm the only one doing this >anyway ;-)). > > Ok. I just added a "build_suffix" option that will become part of the base build directory name.
It allows what you want, but it has some sideffects that I don't think you will like. As setup, scons caches all the options used in a local cache file that is processed for default values the next time you run the build. This means the build_suffix and the other options you use will be cached. And the next time you run scons it will build into the same directory with the same options. This is all fine, but it makes switching to a different combination a little painful because you have to set the build_suffix and corresponding options again. There are two ways to simplify this that I can think of: 1. Write a local script like "scons.mtptr" that calls scons with the correct options. Simple, easy, but a bit of work. 2. There is another file that the option processing tries to load (options.custom). This file can be pure python code that is evaluated at runtime. With a bit of work on my side I could make it so you could get access to command line arguments during the processing of this file. That this would allow is for you to write something like this in options.custom: option_arg = ARGUMENTS[0] if option_arg = "FC": build_suffix = "fc_ptr" fcptr_mode = "MT_FCPTR" elif option_arg = "MC": build_suffix = "mt_cptr" fcptr_mode = "MT_CPTR" elif option_arg = "S": build_suffix = "single" fcptr_mode = "SINGLE_THREAD" Then you could call scons something like: scons FC This method would take more work on my part, but it would allow the maximum flexibility in the future. I just don't know how many people actually need it. :) -Allen >regards, > gerrit > > > >------------------------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >Opensg-users mailing list >Opensg-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/opensg-users > > > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
