[sldev] easybuild branch

[Robin Cornelius]

As Rob mentioned yesterday at his office hour, merging easybuild into
http-texture ASAP is probably a good idea so it gets exposure and we
can chase out any bug/ issues that have appeared with the changes to
the build, I agree if its left in its current branch it will get next
to no testing and when it does get merged some of us may then be upset
as its caused build breakage to our way of doing things.

I've started some testing and hit a few snags already.

1)

Firstly i was under the impression that develop.py was going/being
replaced and/or that the build would be started by invoking cmake
directly? I'm personally against invoking cmake directly for people
who *just* want to build as although the number of parameters passed
to cmake have been reduced by various autodetection its still a messy
process. (but i am 100% for invoking it directly with fine grained
control when generating packages for linux etc)

For standalone it looks like cmake -DSTANDALONE:BOOL=true

and thats not the end of it, that makes a mess in the indra/ folder
that is then difficult to clean, its normal (and what develop.py does)
to create a working folder for the cmake build. Then when you want to
do a clean you can kill that working folder, cmake does not provide a
make clean target, so this is the accepted way of building. without
develop.py this would end up with a command line like :-

mkdir build ; cd build ; cmake -DSTANDALONE:BOOL=true ..

(with or without standalone) thats not so friendly. So i'm not really
sure if this is just a rumor or what is actually happening in this
area. The information has come from inside LL so it would be good to
get clarification on this issue and what the goal is for the initial
invoking process.


2) There is a subtle change to the develop.py on that branch, it
passes the standalone parameter to cmake for both the build and
configure stages (but with the approprate ON/OFF flag set). What this
means in practice (which i panicked over) is that

./develop.py --standalone
./develop.py build

will no longer work, the build stage will start to download prebuilt
packages., because the build call to develop.py has an implicit
STANDALONE:BOOL=FALSE, What this needs to be is now :-

./develop.py --standalone
./develop.py --standalone build

3)

Testing on windows today has failed with missing cursors ( Cannot find
source file "arrow.cur".) at the configure stage. Now i'm not sure at
this point if this is a work in progress and may be today some more
commits will finish this off, but i was under the impression that
artwork-common would now be downloaded and installed by the process.
But i also now notice that artwork-common is not in the install.xml in
easybuild, so i guess this is something gone ahead in trunk and not
ported to the branch that needs it most.

4) Compiler detection and generators

Running the default develop.py on my system from a command prompt (no
generator specified)  with the path/lib/include set up to point at a
visual studio 2008 install (eg a Visual studio 2008 command prompt)
resulted in the cmake stage finding and testing cl and friends from VC
2008, then generating a project for Visual studio 2003.

Basically the "Check for working CXX compiler" will first test the
compiler it finds in the PATH but seems to also find VS2003
professional edition (registry search?) if one is not in the path. So
i guess it searches PATh then registry. But testing any old compiler
in the path or registry is not a great idea when the user has
specified a specific generator on the command line. The compiler being
tested is then NOT the one that will be used for the build and we
already know 2005 express can manage to fail to install correctly and
not have windows SDK available as default, so in this case my 2003
(not supported for secondlife build) would be found and pass the cmake
check but then when i tried to compile in visual studio 2005 it would
fail with missing user32.lib and friends.

5) VSTool.exe and develop.py and express

The combination still fails in a big heap, we know that VSTool.exe
itself is of no use to express builders but the current develop.py
still does not have the express edition patches so will not detect an
express and fails in an ungraceful and confusing manor to a builder,
please see http://jira.secondlife.com/browse/VWR-11138 for a solution


I'll carry on with some further testing and report back any other issues

Regards

Robin