Re: [Opensg-core] [OpenSG 2] Build system, options file name

[Dirk R. <di...@in...>]

	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