[sldev] Heads up - we're working on CMake (and more)

[Dzonatas]

Erik Anderson wrote:
> With so many requests for the CMake scripts, I get the impression that 
> a lot of people are dependent on these script in order to more easily 
> build the viewer.  Why is the entire opensource effort being tied to a 
> developer working on something that is not the main development focus 
> right now?  If there was a strong need for these files, I'm sure that 
> there would be half a dozen versions floating around that could be 
> submitted or used in the interim, such an effort could probably help 
> as it would show potential gotchas and issues that need to be dealt 
> with before such a build process could be adopted.  I mean heck we've 
> even got the guy that wrote the program in here.

I mentioned to Hoffman that it would be a blessing for SCons, CMake, and 
Ant developers to collaborate. Such collaboration surely solve the 
issues when/if it happens. Each has a very powerful aspect to add to the 
build process. For now, we can do use two or more to get the job done 
where it matches every bodies needs.

Ant is nice for its easy IDE integration. It is mainly suited for Java, 
however. Any non-java work involves custom ant tasks. However, such ant 
tasks could be simply a task to keep file lists up to date from the IDE. 
Then the actual builder can vary.

CMake is good to create project files specific to an IDE. It also has 
some installation procedures that can be used; however, a package like 
InstallJammer is even more robust then CMake's installer. CMake requires 
C++ for more in depth customization, so there is some worry there that 
not everything can be done with just langauge CMake uses. CMake doesn't 
actually do the build process, as it is only as good as the builders 
provided with the system for which it create project files to use.

SCons is the more programmatic builder. I get the gist that people 
generally don't like SCons because of the need to understand the 
programmability of it.  In regards to CMake, however, the effort becomes 
similar to work out any in depth customization to CMake. In comparison, 
CMake presents a Makefile-like script, and many are use to that feel. 
SCons, with python being an intrinsic environment, means that any 
in-depth customization is easily portable to any system that supports 
python. SCons has a bit of a learning curve to understand the 
dependencies, but SCons has by far the best dependency tree than any 
other builder I've seen.  SCons is also very smart with what it knows to 
build with signature checks.  The database it uses can easily be shared 
across the network for distributed builds. SCons can also be made to 
call CMake to use the power features of CMake.

As for LL and the jumpy bit, I say people need to think a bit more 
positive. When developers invest a lot of time to their work for reasons 
they believe was the right investment, they hate to see it tossed aside 
or push to the street for no reason -- or at least for no reason being 
stated. It pisses people off one way or another. The obvious solution is 
to collaborate more. I understand if people are skeptical that 
collaboration is not so easy.

I truly see employees of LL truly try to collaborate and integrate with 
the open source community or at least in the principles and philosophy 
of open source, but I can't say every employee does such.  That is true 
for other businesses than just LL.  Hell, I remember when I had to take 
on my own action of procurement and the responsibility for such action 
just to get the Internet into the (very big) business I worked at before 
1995, the Internet boom. I used to access all the powerful tools that 
people collaborated on together. If you remember, most businesses 
despised the Internet before 1995.  Things have change big time very 
quickly. With the dot com explosion, it was like a sudden "likeness."

-- 
Power to Change the Void