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 _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
