[sldev] easybuild branch

[Brad King]

Hi Robin,

I've been the developer committing changes on the easybuild branch.
So far most of the changes have been for delaying download of prebuilt
binaries to build time.  There are also changes that remove dependence
on cygwin (building without flex/bison).

Robin Cornelius wrote:
> 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.

Thanks for looking.

 > 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?

Yes.  One goal is that CMake will be the only prerequisite.  Once the
user runs it it will report what other things are missing (like python)
along with a link to the wiki with instructions.

> 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.
[snip]
> mkdir build ; cd build ; cmake -DSTANDALONE:BOOL=true ..

If CMake is not easy enough to use without a develop.py front-end, then
it will be improved.  We've already planned enhancements to CMake's
command-line usability for a later phase of this effort.  This includes
project-specific command-line options like --standalone.

Manual creation of the build tree has always been the "cmake way"
because we support multiple arbitrarily-located build trees sharing
one pristine source tree which is never touched.  I think Second Life
needs some changes to work with an arbitrarily-located build tree, but
I'm sure it's possible if that is a goal.

One idea to auto-create a build tree is to have some kind of file in the
source tree that tells CMake where to put the build tree if a user tries
an in-source build.

> 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

I've made no changes to develop.py, and it looks identical to that on
trunk and http-texture.  Can you provide more detail, please?

> 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.

The artwork-common change was made after the easybuild branch spawned
from trunk and it has not been merged.  Automatic artwork and libs
downloading is a work-in-progress.

> 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

Actually this is just checking that the already-selected compiler works.
The search is complete by the time this check runs.  Currently CMake
does not take the environment into account when selecting a default
generator.

FYI, you do not actually need to be at a VS prompt if you select a VS
IDE generator.  Only Make-based generators require one to start CMake
from the proper environment.  In fact, you can even run cmake-gui from
the start menu and not use a command line at all.

> 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

Again, CMake will be improved so that develop.py can be dropped.

-Brad