Hi Carsten,
Carsten Neumann 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.
>
> 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 ;)
I like the idea of a local build being essentially an install already,
as that simplifies installation to making a copy, and simplifies testing
the install mechanics (as it's always installed anyway).
> 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 fully agree. I think the variants cause a lot more trouble than they
are worth.
>> 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 ?
Hm, well, they are compiler-realted options and as such IMHO they belong
into the build system.
> 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.
Agreed.
> - .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.
Either one works for me.
> - lib*.so files are put into the build dir.
Yup.
> 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).
See above, having the 'proper location' as the normal location would be
nice.
Thanks
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
