[sldev] easybuild branch

Brad King brad.king at kitware.com
Fri Apr 24 06:33:06 PDT 2009


Alissa Sabre wrote:
>> So far most of the changes have been for delaying download of prebuilt
>> binaries to build time.
> 
> I'm not sure my environment is typical or unusual, but my main
> development machines are not online (i.e., disconnected from Internet)
> usually.  I connect those machines only when necessary.  In a past, my
> practice was something like: download necessary files with another
> machine and copy those files to main development machine locally.
> These days, however, I need to connect my main development machine to
> internet when running develop.py.  I have a feeling you are making
> things worse, i.e., I would need to connect my main development
> machine whenever I build...

If the files are up to date it should see them in your download cache
and not actually touch the network.  You only need to be connected for
the initial build, and then only for building the 'prepare' target.

> What is the primary reason of this change?  What advantage does the new
> scheme have over the current one?

Previously the initial run of CMake took a long time before one could
interactively change any options.  Now it is really fast, and all the
long stuff is delayed until build time which does not require further
interaction.

>> (building without flex/bison).
> 
> This sounds good, especially I'm still having a bison related issue on
> MacOS.  I'm afraid, however, that this change makes it difficult to
> modify .y and/or .lex files.  Hope your change actually means
> "flex/bison are not needed unless the builder changed .y/.flex files,
> and if she/he changed, flex/bison runs automatically to update
> generated .cpp/.hpp files."
> 
> # Am I hoping too much?

If you have flex and bison installed then it will use them and generate
the files.  This makes interactive development easy.  Before committing,
though, one needs to manually run flex and bison using the instructions
in comments at the top of the sources.  One must commit the input files
and output files at the same time.  Otherwise if a user builds without
flex or bison he/she will get an out-of-date parser.

This extra effort for the developer is traded for simplifying the build
for users.  Dropping cygwin as a dependency of windows builds is a win.

>> 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.
> 
> So, you are changing CMake itself?  Great!

We plan to make a few tweaks to CMake's interface, mainly to ease
command-line usage.  The issues you raise below are out of the scope
of this effort.  I'll briefly comment on them, but this is not the
place for full discussion of CMake-specific topics.

 > Following is a list of my own wishes on CMake improvement that I
 > believe facilitte SL development:
> 
> Proper handling of platform-specific file system features.  E.g., on
> MacOS, a mount point for Windows (SMB/CIFS) file server has a
> semicolon (;) character embedded in it, but the current CMake can't
> handle such full-path name.

The CMake language use ';' as a list separator.  This cannot be
addressed without major fundamental changes that are incompatible.

> Or, on Windows, file names are case
> insensitive but CMake seems file names case sensitive ways, causing
> trouble if the SL source files are placed in a lo0cation whose
> full-pathname contains upper-case letters.

My Second Life sources are in ".../My Programs/SecondLife/linden" on
windows and it works fine.

> Avoid coding full-paths and options on Linux.  I have a feeling that
> CMake likes to embed full-paths to, e.g., compilers and other tools or
> fully expanded command line options to the build tools in the
> generated makefile's

Changing compilers in an existing build tree is not a case we optimize.
If one does change the compiler, everything needs to rebuild because
CMake cannot be sure the new compiler provides an identical ABI.

That's why we support out-of-source builds.  Just create as many build
trees as you have compilers, and you never need to change compilers
in an existing build tree.

> Fine build dependency.  I also have a feeling, although not sure, that
> the CMake generated build files contain unnecessary build
> dependencies.   A significant effect of this is tyhat, when any of the
> library subprojects failed to build, any source files in the newview
> directory are not compileed and the build process stops.  Because
> those libraries are only needed upon linkage, steps before linkage
> should happen.

CMake takes a conservative approach here.  It is possible that one
of the libraries to which an executable links contains a custom
command to generate a header file that will be included by some
of the executable's source files.  If the library has not finished
building before we start to compile the executable's sources then
the header may be missing or out of date.

I suggest running 'make -i' to ask make to keep going despite failures.

 > Another observation is that when modifying a header
> file in a library subproject, a lot of source files that doesn't use
> the modified header file are re-compiled.

I'll be surprised if this is the case.  Next time it happens, try
preprocessing the object that you don't think should have rebuilt
to see if it uses the modified header.  You can also run "make -d"
to see why it decides to rebuild something.

> A related _wish_ to easybuild is a co-existance of standalone and
> non-standalone build directory based on a single source tree.

This is a develop.py limitation.  CMake has full support for truly
out-of-source builds.  Just create your own build trees and run CMake
directly.

-Brad


More information about the SLDev mailing list