No subject

expecting the switch over to take a lot longer which was something I
was planning on as a bunch of Mac critical features we need from CMake
are not implemented yet. I was hoping CMake would implement these
before OSG was ready to switch over, but that doesn't look like it
will be the case.

I will admit that I really dislike the CMake description language. But
for common stuff, CMake provides reasonable APIs, so you don't have to
do much in the language itself beyond calling the APIs. So this way
better than having to figure out and writing autoconf/M4.

But the real reason to use CMake is simple. It offers better native
platform and IDE support than any other cross-platform build tool I
know of.


Anyway, I've been meaning to follow up with you on the CMake stuff for
Producer. Did you find those scripts still to hard to understand? I
tried to make it as straight forward and simple as possible. I've also
been meaning to follow up with you on Producer/Cocoa. But I've just
been swamped. The OSG/CMake effort has monopolized most of my free
time.

Thanks,
Eric





> Hi Producers,
>
> Well,  it seems that OSG has now gone to a complete CMake system for
> building.  There seems to be some mixed opinions about this move.  GIven the
> fact that the original build system is nearly entirely my creation, I feel
> entitled to offer my opinion about this move and my plans for Producer with
> regards to build systems.
>
> Currently, you will find two concurrent build systems in the Producer tree.
> One that is based on CMake, as contributions, and the other based on
> DWMake.  DWMake, as a reminder, is simply the improved general concatenation
> of the build systems for OSG, Producer and OpenThreads.  (Robert referred to
> it disparingly and declared emphatically that OSG would not move to DWMake,
> even though he had already been using it for nine years).
>
> The way I see it, there are four types of users of any middleware open
> source project (all users referred to here are programmers, developing
> applications with the middleware):
>
>
>    1. Binary users
>    2. Compile-Once users
>    3. Cross-compile users
>    4. Developers
>
>
> Binary Users:
>
> These are the folks who simply want to begin using a software platform.  I
> consider myself a binary user whenever I have to work under Windows.  I'd
> much rather download a binary version of osg and start writing code against
> it, rather than go through the headache of building the entire tree
>
> Compile-Once users:
>
> These are users that fit into the Binary Users category, but cannot simply
> use a binary version of the software because they have specific compiler and
> run-time versions that don't fit into the category of the provided binary
> versions.  For example, in the case of osg, they want the debug libraries,
> or libraries built against visual studio 8, not 7, or gcc 4.x, rather than
> 3.x, etc.  For these folks, the exercise becomes one of downloading source,
> compiling it as quickly as possible and then turning to the task of building
> their application.
>
> Cross-platform users
>
> Cross-platform users are those who need the software for various different
> platforms.  These are also folks that might fit into the Binary Users or
> Compile-Once users categories from a working standpoint (that is, they
> simply want to focus on the task of building their application), but must
> support multiple OSs or compilers.
>
> Developers:
>
> Developers are programmers who will take a more introspective view of the
> middleware they are using.  These are users who will walk through the
> middleware code, become familiar with it and make contributions to it, bug
> fixes, etc.  These also include the authors of the project themselves.
>
> The right tool for the right job
>
> Some of you who have been around long enough, might recall that we dabbled
> with autoconf a few years ago.  We ended up rejecting it because of several
> reasons.  1. It bloated the tree, 2. It nearly doubled compile times 3. It
> required us to change the configuration and regenerate with ./configure from
> the root everytime we made a change or addition.  For developers (Robert and
> I), this was miserable.
>
> However, what we didn't consider was that many who were accustomed to
> downloading an open source project, looked for the ./configure; make; make
> install sequence.  The other piece of it was that we focused on development
> under Linux and Visual Studio and XCode were simply more headaches for us.
> That is when CMake and SCons were suggested to us.  I bought a book on CMake
> and read it through, but I must confess that I never got comfortable enough
> in it to be able to develop the build system that worked like DWMake for
> development.
>
> So, considering the three categories of  users who might build the source
> code, here are the pros and cons of three build systems:
>
> Autoconf/Automake:
>
> For the Build-Once or Cross-Platform users, this is not a bad solution.
> Since the software is only built once, it doesn't matter that it takes
> longer or bloats the tree, since once the binaries are installed, the source
> tree could be done away with, or cleaned.  A further advantage of
> Autoconf/Automake is that the scripts are native to the source tree and
> platform and don't require additional software to be installed.
>
> For Developers, however, this is really miserable environment to work in.
>
> CMake:
>
> I must defer to the fact that the CMake folks seem to have won over the
> SCons folks in the choice between these two build systems.  What CMake seems
> to do best is satisfy the need for cross platform build environments, by
> providing Makefiles, Visual Studio files, XCode files, or even KDevelop
> project files for various types of build environments.
>
> The down side of CMake is that it requires an additional software package to
> be installed.  This also brings into light the issues of versioning and
> maintaining the CMake configuration files in synch with the version of CMake
> that you have.
>
> The real advantage of CMake is for the author of the project as he needs
> only maintain the configuration files, not the native build environments.
> The advantage for the Compile-Once or Cross-Platform user is that the result
> is a build system in the develpment environment of chioce without the worry
> that the author may not support your environment, or may not have brought
> your environment up to date.
>
> DWMake:
>
> DWMake provides great benefit for the developer in a Unix environment.  What
> DWMake does is provde a set of build targets for expedient and efficient
> development environments.  Besides the simple, one time, 'make' command,
> there is also the use of symbolic links to keep development environments
> properly synchronized.  'make debug' allows the developer to quickly change
> from an optimized version to a debug version without having to rename
> files.  'make instlinks' allows a single version of executables to exist on
> a system.  Concurrent build systems can reside in the same tree, etc.
>
> DWMake is a system that I have learned to work with over the years and have
> yet to find something that is as efficient for setting up, building or
> installing on a Unix system supporting gmake.
>
>
> So.....
>
> My current thoughts are that I would like to continue to have concurrent
> build systems.   I had originally hoped to take DWMake out of the
> distribution, so it is an optional build system.  However, my first move
> toward doing this came at an unfortunate time when any move I made in
> Producer land was blown out of proportion. In retrospect, the motivations
> for these exagerations had little to do with the health and well-being of
> build systems, so my inclination is to take DWMake out of the Producer
> build, and allow users who want to build Producer checkout either DWMake,
> CMake, or use the autoconf generated files in the distribution.
>
> Your thoughts?
>
> -don
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://andesengineering.com/pipermail/producer-users/attachments/20070411/63029908/attachment-0001.html
>
> ------------------------------
>
> _______________________________________________
> producer-users mailing list
> producer-users at andesengineering.com
> http://openscenegraph.net/mailman/listinfo/producer-users
>
>
> End of producer-users Digest, Vol 11, Issue 1
> *********************************************
>