[sldev] easybuild branch

[Alissa Sabre]

Hmm.  Easy build sounded a good direction at its first place, but
reading the message from Brad makes me worry ...

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

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

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

> 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!  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.  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.  Moreover, in some non-US
versions of Windows, users' home folers contain non-ASCII characters
as default, and the fact makes CMake behave worse.

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 It is against the well-accepted conventions.
Instead, the makefiles should refer to standard make variables, e.g.,
CXX, AR, CXXFLAGS, LDFLAGS, etc.  One of the negative effect of this
seems that we need to decide whether use or don't use distcc upon
running develop.py, and if we change it after that, all source fikes
are compiled again from the beginning.  I hope it is not the case in
the new easybuild.

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.  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-compileed.  It greately slows down
development iteration on my poor development machine.

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

I believe this happens on 1.22 and on trunk.  So this issue should be
unrelated to easybuild.

A related _wish_ to easybuild is a co-existance of standalone and
non-standalone build directory based on a single source tree.
Currently, develop.py creates build directory of the same name
regardless it is standalone or not, so I need to have two separate
copies of source files to test both standealone and non-standalone
builds on one Linux PC.  Moreover, "develop.py --standalone configure"
downloads prebuilt files into "library" directory just next to "indra"
directory, and existance of prebuild header/libraries files there
seems affects behaviour on standalone build files.  It is problematic.

    Alissa Sabre
--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/