[sldev] easybuild branch

[Robin Cornelius]

Brad King wrote:
> Hi Robin,

Hi Brad,

Thanks for the reply,

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

Yes seen those and tested them. Also seen you have the FindNDOF.cmake
implemented, but please have a look at
http://jira.secondlife.com/browse/VWR-10579 i've added some extra
comments (and patch) as the patch applied is still broken and not
enabling NDOF in standalone mode.


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

Ok that clears things up. Currently it was just rumours floating around
about how this was going to work.

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

I'm all for cmake improvements if they simply the build process, I
assume you mean a general project-specific command line option that any
user of cmake (not just secondlife) could utilise by crafting there
CMakeList.txt correct with new commands etc. An important goal of what i
do is building the viewer using only standard distro supplied utilities
and libraries on common linux distributions so if custom versions of
built tools were required this would be very bad, but again i assume you
mean a general cmake change.

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

This sounds interesting, I think it would be very useful to allow the
build location to be set via CMakeList.txt or the command line. So the
current way still works but a new system of allowing some function like

set_build_directory("build")

so this could replace or provide an alternative to the :-

mkdir build ; cd build ; cmake $some_options ..

which i think would be used my many. Also would allow thinks like

set_build_directory("viewer-${ARCH}")

to replace what the current develop.py does now.


>> 2) There is a subtle change to the develop.py on that branch, it
> 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?

This may have happened some time previous to the branch off, but its
more informational than important and if you plan to kill develop.py
anyway it really does not matter.

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

Ok great.

Something that has been brought up with LL a few times recently is how
to handle the artwork-common package for standalone builds. There are
two ways that probably need to be considered. One where the artwork is
automaticly downloaded for the standalone builder, so they still use
system supplied libs but they don't need to manually grab the artwork.
the second is where the artwork may not be in the build tree at all and
will only appear in the final location when the binaries are installed
on the target system (eg what happens now on debian packages of the
viewer and artwork).

So what i would like to see is as follows

1) Standard build automaticly grabs everything
2) Full standalone, no artwork in source tree
3) standalone with automatic artwork fetch

> 
>> 4) Compiler detection and generators

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

My only concern here was that the compiler used to test the compiler
functioned was not the same as was used for the actual build. Some of
this may have been confused by the develop.py stage. So hopefully by the
time that is removed it will all just work correctly.

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

I can see how the existing functionality of vstool could be integrated
into cmake. But please remember this does not and cannot work for
express editions of visual studio as they do not support the API's
necessary for automated editing of the solution, needed for setting the
project user options file that contains the default working directory,
the start up project and the build type, to name a few options.


Something that has not been discussed is the install target.

Currently there is a cmake install target provided for standalone and
this does indeed work (with one minor patch that is imported to some
internal LL branch). This is still very much required by some of us as
again we want fine grained control over the naming of the binary and the
exact locations of the main binary and the data files. What is there now
does work so please keep that intact. Not all of us want to produce
tarballs of the viewer the way LL currently do by default.




Thanks for your time

Robin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090420/8a1c2b53/attachment.pgp