Length warning! As a preamble, I want to make it clear that I'm not a
proponent of Stop Energy.
http://www.userland.com/whatIsStopEnergy
I throw cold water at people, then tell them to knock themselves out
with whatever they feel needs doing.
Tanguy Krotoff wrote:
Brandon J. Van Every wrote:
People who feel neutral about Autoconf, or who are in fact pleased
with it, aren't going to up and do anything for Windows anytime
soon. For those people, it will take a *long* time for migrations to
happen via CMake.
I do not agree, yes it will take time but if you provide a much better
tool that the existant one (+ in some extend is compatible with the
old one), developers will switch.
CMake is not compatible with GNU Autoconf. It merely achieves similar
functionality with a cleaner architecture on more compilers. So the
cost of switching a 75K LOC project like Chicken Scheme can easily be 1
man year. Granted, we had a quick and dirty version within days, and
that's a powerful selling point. But to actually duplicate the full
functionality of the Autoconf build, while maintaining the stability of
the old build, took 1 year. That's because builds for non-trivial
projects have layers and layers and layers of STUFF that people don't
think about when it's all working. Also because it's one thing to do a
CMake only build, and another thing to do a GNU Automake only build, and
a quite different beast to have the two play well together. I did it;
it was a PITA. And I'd hate to think how it would have gone if the
political landscape had been different. When making an architectural
decision I only had to convince Felix, the principal author, and his
coding aesthetic sense is similar to my own. What if I had had to
convince a committee?
When projects are that expensive to re-architect, people don't just
"switch." They carefully consider their options only when they're in a
lot of pain. So if a Linux-loving Autoconfer's build is working more or
less ok, they ain't fixin' what ain't broke.
We can reduce migration time by simply providing a very nice and
simple API for building software using CMake, and the first step
Frankly, lots of steps have been taken already. You're talking about
cleaning up warts, not "first steps." If you're deeply interested in
conquering the world with CMake, why not join the cmake-promote mailing
list? Technical fixes aren't the only things that CMake needs.
Although, in practice, they've been the easiest for me to provide (in
the form of bug reports), for the energy I've been willing to expend.
is to fix little things like:
if (GCC) and not if (CMAKE_COMPILER_IS_GNUCXX)
if (ICC) and not if (CMAKE_C_COMPILER MATCHES "icc")
an API should be *consistent*, if you choose to have
if (MSVC)
if (MINGW)
then you should have if (GCC), if (ICC)...
I agree that these are inconsistent / not so good / not so desireable.
Feel free to file a feature request, or even to implement them if you're
facile with the sources. I'm not, so I make feature requests. Or if
something is not really a feature, but rather documentation that is
rightly considered missing, I file a "content" bug. I find that these
sorts of low priority items do tend to get dealt with 1..2 months after
I file them. That is to say, filing coherent feature requests /
documentation bugs does count as action on your part.
And saying "there's coverage, it's just ad hoc, not canonized, and has
an inconsistent interface. At present this doesn't trouble me,
personally" won't help
Right. Goading *YOU* into filing the feature requests you are
discussing *WILL* help. ;-) I already went up this learning curve,
these issues aren't cramping my style. Documentation issues were
cramping my style in a big way, so I filed some documentation bugs a few
months ago. I didn't get everything I wanted, but the docs do have URL
pointers to the online wiki now, and that's a significant step forwards
for newbies fumbling around. In the constellation of all my present
programming priorities, I'm currently at peace. Your itch; so go
scratch it.
CMake users don't care about CMake, they only care about building
their software and they don't want to google/read the doc because if
(MSVC) works and if (GCC) or if (ICC) don't as they expected.
Actually they do want to read the docs, and that's why I filed content
bugs about it, because in a number of instances it was rather difficult
to find what they needed to know, even if they were making concerted
attempts to RTFM. Here's how I see the priorities:
1) API works
2) documentation is findable
3) documentation is complete and clear
4) API is consistent
A more important issue, you can write:
add_definitions(${DEF})
include_directories(${INC})
but you cannot write:
add_compile_flags(${FLAGS})
add_link_flags(${FLAGS})
!!!!
No this would be too simple... so you have to check the doc, google
and finally find out that it works in a totally different way!
set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS ${FLAGS})
But, this drill has never been a stumbling block for me personally. If
there's a way to do it, and it's documented, I can read how to do it. I
don't expect to automagically intuit how to do stuff on the basis of API
consistency principles. I expect to RTFM, quite a number of times,
until I know what to do. Consistency of API just makes it more
palatable and enjoyable. It doesn't obviate RTFM.
Most of CMake works like SET_TARGET_PROPERTIES, with verbose tags for
the next field of input. The API may not be 100% consistent in this
regard, but it is probably 85% consistent.
I did get starter code for the Chicken Scheme build once upon a time.
Seeing code that actually works, definitely helps. That's part of why
I've tutorialized the Chicken Scheme build, so that newbies can see what
they actually need to do. You can certainly take the tack of perfecting
the APIs, but another equally valid approach, is to provide good
tutorials and repositories of sample code. I don't really want to learn
anything, I just want to look at how things are done and copy them.
CMake may not be a perfectly refined API, but typically it works, and
it's a helluva lot better than the GNU Automake stuff!
Actually one way that Automake is "better" than CMake, is it has much
more complete documentation, with examples, caveats, pitfalls, concerns,
etc. This is all in their standard shipping documention. Of course,
they're documenting a build system spread out across Automake, Autoconf,
Make, and Libtool, so the end results are horrid and there's plenty of
hunt and peck. But it's a *darn well documented* horrid mess.
Your answer will probably be "not happy? send a patch!"
and here is my patch:
http://dev.openwengo.org/trac/openwengo/trac.cgi/wiki/OWBuild
http://dev.openwengo.org/trac/openwengo/trac.cgi/browser/wengophone-ng/trunk/cmake/Modules/owbuild
This isn't a patch though. This is a derivative work; you're running
off in your own direction. Do you have a patch for the
ADD_COMPILE_FLAGS, ADD_LINK_FLAGS inconsistency you describe above?
Minor adjustments like that would be worthwhile.
This permits me to create build scripts for cURL, PortAudio,
libGaim... in 1h, check how simple they are !
Even somebody who never heard about CMake can understand them...
I applaud the effort and skill you have put into this! But...
...there's the important issue of whether people who *HAVE* heard of
CMake can understand them. If you macrotize all the CMake code out of
existence, then people have to dig through your code and documentation
to understand what's going on. If people need help with what's going
on, they have to ask you, because nobody else in the CMake community
knows what's going on. This makes you a single point of failure for
other people's projects; many people won't use stuff if there's only 1
guy who "supports" it. That of course can change over time if your code
does in fact prove to be really really useful; you could conceivably
build a higher level community around your offerings. But it takes years
to establish such utility, and you have said yourself, you are hardly
finished.
The worst code I wrote for the Chicken Scheme build was the heavily
macrotized stuff. A few passes later I ended up getting rid of it. In
the real world, with real people banging on your build who don't know
what's going on, the dumb way is often the maintainable way.
Since I have a very high level API, I can do very high level things
like choosing from the cache if I want a shared or a static library
(and don't tell me the problem is a simple -DMYPROJECT_EXPORTS), copy
automatically files on the fly, integrate an inheritance system...
It's not fully finished yet, I have to write more doc + test deeply
the macros
Now I'm scratching my head: do I extend my macros and add if
(OS_WINDOWS), if (OS_MACOSX), if (OS_LINUX), if (CC_MSVC), if
(CC_GCC)... or do I stick with if (APPLE), if
(CMAKE_COMPILER_IS_GNUCXX) and if (CMAKE_C_COMPILER MATCHES "icc")??
Are you a team player or a maverick?
CMake is a wonderful tool, very glad people are developing it but
please create a simple, consistent and high-level API and then people
will switch
The crux of what I feel we're arguing about here, is what I see as your
notion of "build it, and they will come." The history of the software
industry clearly demonstrates that perfectly clean APIs are not
generally the winners in the API wars. Adoption decisions are driven by
other considerations, like:
- how many $$$$$$$$$ is locked up in this API?
- what is the maturity of this API?
- what is the stability of this API?
- what is the size of the support community for this API?
- what is the current popularity?
- does it work?
- does it do what WE want?
- can we make it do what we want?
I hope you're willing to work with the CMake developers to make
improvements that a quorum of key people feel are desireable. Note: I
deliberately do not say "most people," as I don't believe in Stop Energy.
You don't need to spend time convincing people here about the merits of
cleaner APIs. The CMake developers value cleaner APIs, and it's a
cleaner architecture than GNU Autoconf by far. However, there are
implementation considerations, as CMake is a *successfully* evolved
project. Some things are easy to do, some things are not. Some things
are easy but not desireable, because there are maturity / support issues
to consider. What you need to do, is plug your thoughts, reproducers,
and patches into the bug tracker. http://www.cmake.org/Bug That's how
things actually get done around here. And, they do get done, if not
instantly.
Cheers,
Brandon Van Every
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
