E. Wing wrote:
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.
Perhaps those already familiar with CMake are knowledgeable about
pathname issues. But I will dispense some advice here in case people's
knowledge or habits are incomplete. It is typical for a CMake developer
to do so-called "out of directory" builds. That is, the source files
stay in one directory totally untouched, and a build directory is
generated with all the stuff that is actually built in it. You can do
in-directory builds of course, but as a matter of habit it is best to
assume that the user will be doing out of directory builds. There are,
after all, quite a lot of different build generators to choose from in
CMake. I build MSYS, Cygwin, and VS .NET 2003 targets regularly on the
same Windows box, for instance.
This means you're going to make a lot of use of these 3 variables:
${Myproject_SOURCE_DIR}
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR}
I use the 1st one whenever I'm accessing sources from the source tree
that should be considered read-only. I don't tend to use
${CMAKE_CURRENT_SOURCE_DIR}, but that's only because all the Chicken
Scheme sources are conveniently contained in 1 directory. I use
${CMAKE_CURRENT_BINARY_DIR} for everything and anything that is
generated. In particular, I often have cause to write a MACRO that is
meant to work in a similar way in several directories. For instance,
this is a typical bootstrap compiler problem. The 1st stage is in a
subdirectory /boot, the 2nd stage is in the main directory, and I don't
really want my build rules to be terribly different for these stages.
It is often not necessary to qualify your filenames with these
variables. If you say something depends on "toast.c", it'll just look
for toast.c in the source directory or current binary directory, as
appropriate. The reason I get into qualifications is I'm doing a
compiler. I have different build stages and lotsa overlapping names and
I'm paranoid about what is what. So I fully qualify. It keeps me out
of trouble. YMMV about whether you need to. But if you write
generators of any sort, like you create .exe's that then go on to
produce source code for your next build stage, you'll get into full path
qualifiers.
Another thing to be aware of, that is FAQ material, is if you use
CONFIGURE_FILE, you have to provide absolute pathnames. This is a
consequence of the "out of directory" philosophy. By design, CMake
considers it an error to use relative paths, because it means you
probably don't really know what you're doing. So, if you've got any
substitutions to perform like config.h.in --> config.h, be aware of the
need for absolute paths. ${Myproject_SOURCE_DIR} and
${CMAKE_CURRENT_BINARY_DIR} do expand to absolute paths, so you do have
the needed tools at your disposal.
> - 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.
Clever macros are not maintainable. I did a fair chunk of
not-brilliant-but-potentially-labor-saving macros for the Chicken Scheme
build, at an intermediate stage of my design. They provided
abstraction, but abstraction is not that desireable in a build system
that's going to be worked on by other people. If someone else is going
to come in and fix something, it is far better that they see straight
CMake code and a list of files to tweak, so that they can just do that.
Understanding other people's abstractions is a big waste of time, as one
must go up the learning curve of what the hell the other buildmaster
did. Also when you want to post a problem to the CMake mailing list, if
you've hidden CMake's functionality under a plethora of macros, you're
gonna be SOL as far as anyone helping you. What people can talk about
and help each other with, is straight CMake code. And especially,
isolated reproducers of problems, which is more and more difficult if
buried under abstractions.
You really have to consider if a macro is saving you significant work,
vs. whether you're just doing it out of a perceived need / habit to
abstract. I know programmers like to abstract, but it is often a bad idea.
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.
Yes, that's a facet of maintainability. For instance, Felix Winkelmann,
the primary Chicken Scheme author, knows the ./configure build more than
I do. He tends to leave CMake matters to me. So if he makes some
sweeping change, he typically greps for all occurrances of whatever file
he's changing / nukeing and does a pretty good job of covering his
tracks. But there is inevitably something left over on the CMake side
that I have to clean up. He catches things like myfile.c, but not
things like "myfile" used as a rootname in a bunch of my macro stuff.
In the real world of open source development, people don't have time to
hunt down every last one of someone else's stupid changes or
oh-so-clever build rules. The bugs just show up downstream. They do
tend to get caught, as build bugs tend to break things, but it means
delays in regaining the stability of the source tree.
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.)
I find that testing for external tools, like "do you have Darcs?" "do
you have makeinfo?" to be unnecessarily painful in CMake 2.4.3. If you
intend to be thorough about whether the tool actually works, and give
graceful errors when it fails, then you have to write CMake script code
to do the tool testing. This is not wrapped up in some kind of easy
interface and I feel it should be. EXEC_PROCESS *looks* like it's that
easy interface, but it actually isn't, as it doesn't evaluate in the
correct context to verify if the tool will work during the build. The
correct thing to use is TRY_COMPILE with a trivial CMakeLists.txt, and
to generate that trivial CMakeLists.txt if you don't want it sitting
around in the build tree. This is a PITA of a learning curve to go up,
honestly. I can solve such things with a generic CMake script, thereby
benefiting all of CMake-kind, but I haven't had time to implement it.
Meanwhile, in Chicken Scheme, makeinfo went away for other reasons, so
that end-user tool is gone. Darcs is only needed by someone who's gonna
produce a distribution tarball, so I currently feel it's acceptable to
die in an unclean way. After all, it's probably only Felix or myself
that will be doing that.
I find testing for header files and libraries to be pretty easy.
Modules to handle that are already there, and they even handle corner
cases like "is this function available?" vs. "is it available as
symbol?" Now, what you're going to do with the results, well, you're
going to have #ifdef's in your C/C++ code. It's your source code's job
to handle the permutations, not the build system's.
Anyways, you can test external tools all you like. The functionality is
there to do it. I'm just saying it's not convenient. It requires you
to know more about CMake scripting and method of operation than you
should have to. It forces you to become at least an intermediate CMake
buildmaster rather than a novice.
Of course the quick and dirty way to deal with external tools, if you
don't care about actually verifying that they work, is to just
FIND_PROGRAM. That's it, you're done. If the build fails later, and
someone bugs you about it on a mailing list, you say, "Go install
such-and-such." It's acceptable for some kinds of development. I just
have my ego and reputation on the line about getting people to accept my
CMake build, so I don't want any ugly failures like that.
Cheers,
Brandon Van Every
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
