Sorry for the delay in response, but today I' ve been almost ot of office.
E. Wing wrote:
> - Need to place CMakeLists.txt directly into the source tree (to mimic
> current GNUMakefile layout)
It would be great... but do you have commit access to OSG repository?
this was the main reason to keep the folders separate
Only Robert and Don have access. But I think we need to write it as it
were going to be committed because it is easy to start using relative
paths within scripts and if the layout changes, that will have to be
fixed. If we can agree to a stable layout, then we could request
getting committed early as the CMakeLists.txt don't conflict with
anything.
Meanwhile, I'm just using find/tar (or zip) to help me isolate the
components:
That's an option... but with Macros, it has been quite simple to cope
with a parallel make dir
> - Change the current clever file glob into a boring/dumb manual opt-in
> to build
Do you mean writing explicitly the .cpp in the CMakeLists?
OSG has such an ordinate source tree that one can count on the fact that
all the sources are relevant
And headers :)
I really do like the slickness of your macro/function. I've been
struggling with whether this is the best approach or if the
dumb-explicit thing is the best approach.
The big problem is when you're working in a non-stable or non-rc
source. On several occasions I have spotted source code that resided
in the tree that was not supposed to be built. (And sometimes I add
files myself when doing internal development, but they are not compile
ready.) I think it's safer to explicitly opt-in because of this. There
are no surprises in this case.
This is true.. but doing search inside CMakeLists ease the task of
following CVS evolution:
it allows to just run cmake and build, even if some file has been added.
It seems to me that very rarely Robert added to CVSa .cpp that was meant
NOT to be compiled... but we can ask Robert
if this assumption is sound and if he would prefer explicit listing of
files.
Since when I found those Macros (the idea is not mine) I' ve been much
more happy with CMake.. and I' m considering assuming
no .cpp files is ment NOT to be compiled..... so I need not to duplicate
info: the .cpp file list is inherently present within the dir listing.
There is a secondary thing I like about having all the files listed
explicitly. Doing so makes the CMakeLists.txt somewhat
self-documenting and easy to search. I know when I was going through
the prototype scripts, I was searching for where the osg core files
were added, but I couldn't find it initially because I was expecting a
large list of filenames I recognized. Since the prototype system only
worked on Windows and I was on OS X, I started operating under the
assumption that it wasn't written yet. It wasn't until much later I
figured out what was really going on. So I think having this
information explicit in the scripts would be useful to newcomers that
are not familiar with our build system.
I think that macros should be thought as building blocks, so one usually
use them and only occasionally, if something goes wrong,
have to dig inside. Probably some comment should be added to explain the
usage.. and for sure the code cleaned (shame on ,me....)
That is one reason I'd not dared to commit my code on the osgCmake
svn.... it mostly work... but is not clean at all...
I'm not familiar with Use files. How do these differ from the
Findosg*.cmake files?
Use files are for projects that USE OSG: they code the paramenters,
building path, config options and what is perceived to be necessary to
pass to a
CMakeList projects that build a library or an applications that uses OSG.
I think they are very useful: they can be configured for using build, or
install dirs, debug or release.
I' ve used them to build CMake for the osgToy project, it would be nice
to port also NPS tutorials, so we could have them for Linux and Mac also.
As I had understood, Find modules are for finding dependencies that are
not built by CMake; Use and Config files can be generated when you build
a CMake project
to help other CMake projects to use it.
> - Add gui/configuration options to control which components are built
> - Add detection for optional components
> - Add platform specific options (OS X framework or .dylib, etc)
> - Add preference support (built static or dynamic, 32-bit or 64-bit
> (or obese in OS X?),etc)
I think I've figured out how to support Doxygen. Maybe there's a more
elegant way though. (I've sent a horribly incomplete snapshot of what
I've been working on to Jacob.)
Geat!! I' m interested in Doxygen as well..... we have to set up a new
repository or revamp the old svn osgCmake....
what do you think?
I have something for OpenThreads and
Producer. OSG has multiple Doxyfiles and a footer.html file which I
haven't figured out what to do with yet.
Detection for optional components is kind of necessary for the
osgplugins, especially on the non-OS X Unices (and maybe Windows too)
because it is hard to know what's actually installed on these systems.
It is alreay there: the building of gif,jpd,gdal,... and even terrain is
inserted only if
FIND_ (gif,jpeg,gdal) is set
For example, a GIF library may not be installed on the system. We need
to know not to build the osgdb gif plugin.
almost done, the problem is wetehe ro notify the user or not: I' m not
so proficient in CMake to know how to clean
build a configurationuser interface to both let user select the plugins
to build and be notified to provide a needed dependency
The other stuff that responds to user configuration might be
secondary, but I'm worried that because there are enough options, it
will impact the design of our CMake scripts which is why I bring it up
now. (I can imagine every CMake command will either be surrounded by
(multiple) IF cases or contain variables in the command or both.)
again .. code dirty.. probably we would need some example of good CMake
code...
Thanks,
Eric
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
