Re: [CMake] Suggestion for CMake platform/compiler detection
Brandon J. Van Every wrote: Sure. But OpenWengo isn't a patch. I'm sure everyone will be very happy if you submit *small* patches, bug reports, and feature requests in the bug tracker for *CMake*. Nobody wants the entireity of CMake to be rewritten in a higher level style. They want incremental improvements of general value to the CMake community. Yep but this is the problem... it cannot be made of small patches, how can you integrate a kind of inheritance system with small patches to CMake? It changes the API... So for now the best is I work on it on my own and when ready publish on its own repository with a good documentation and try to convince people that it is a better approach. -- Tanguy Krotoff [EMAIL PROTECTED] http://openwengo.org ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
Yep but this is the problem... it cannot be made of small patches, how can you integrate a kind of inheritance system with small patches to CMake? It changes the API... I'm not sure to understand what you call inheritance system. There is already an inheritance system in CMake. For instance, here we have a top level CMakeLists.txt and all CMakeLists project actually inherite already from the top level settings with the ADD_SUBDIRECTORY() command. If needed, the low level CMakeLists can override the inherited settings. So can you explain what do you mean by inheritance system please ? Sylvain ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
Tanguy Krotoff wrote: Brandon J. Van Every wrote: Sure. But OpenWengo isn't a patch. I'm sure everyone will be very happy if you submit *small* patches, bug reports, and feature requests in the bug tracker for *CMake*. Nobody wants the entireity of CMake to be rewritten in a higher level style. They want incremental improvements of general value to the CMake community. Yep but this is the problem... it cannot be made of small patches, how can you integrate a kind of inheritance system with small patches to CMake? It changes the API... Then you are not really working on CMake, and that was my point. So for now the best is I work on it on my own and when ready publish on its own repository with a good documentation and try to convince people that it is a better approach. You'd be better off isolating something about your design that's actually patchable into CMake. It's going to be a long time before you have the support community and growth curve of CMake. There are a lot of competing build systems out there, and CMake is gaining momentum as more people contribute to it. KDE in particular is the project that everyone is watching. Nobody's trying to stop you from contributing to CMake. But you need to *contribute* to CMake. Not just say, I don't like it and I want to change it all. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
Brandon J. Van Every wrote: 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. And? of course I know that. I didn't do it for fun, I've created all these macros because I need a build system as simple as possible with high level functionnalities and I think it can help people to switch to CMake if parts of it was integrated Why do I need something like this? OpenWengo integrates FFmpeg, cURL, OpenSSL, LibGaim, GLib, Boost, PortAudio, Qt4, TinyXML, oSIP, oRTP, eXosip + all the OS specific libs: DirectX, V4L, XVideo, ALSA, OSS, QuickTime... + in some extend IAXClient, Java libs, Objective-C, XUL/XPCOM... + of course we have a lot of internal libraries In the future we will integrate even more stuff: VNC, libjingle, GTK+... And everything should compile and work under Windows (MSVC), Linux (GCC) and MacOSX (GCC) We have more than 100 CMakeLists.txt and for now we have 2 build system: CMake + SCons (an extended version by us). In the past we were using QMake aswell. A clean checkout from the trunk is more than 200MB and something like 10 people fulltime are working on it... This is an improvement over CMake so don't you think there might be some nice ideas and improvements that can be added to CMake? -- Tanguy Krotoff [EMAIL PROTECTED] http://openwengo.org ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
Brandon J. Van Every wrote: Alan W. Irwin wrote: This example of how CMake has quite casually taken over one autotoolized project reflects in my opinion the fact that we live in a chaotic world where small positive actions often have large positive consequences. So in such a world careful planning, discussion, and paying attention to nay-sayers (who automatically always claim you have not done your planning carefully enough) can actually be counterproductive time wasting. Instead, my advice is to take small positive actions (show them the code) to see what might happen whenever you have the opportunity to do so, and always try to identify nay-sayers (those who seem to get a kick out of always being negative) and ignore what they say :-) I would have never undertaken the Chicken Scheme build without Felix's buy-in as a prerequisite. It sounds like you had some authority to make things happen in the PLplot project. Or at least, your findings would likely be taken seriously by a core group of programmers who knew your work. Not everyone is in that position. Not everyone coughs up the initial labor either. It would be useful to track the status of CMake-ifying projects, to see who thrives and who dies out. For the record, I crossed the finish line, then the proverbial medics carried me away on a stretcher. Some private discussion with Bill has made me realize I'm not providing enough context for what exactly is hard. Many of the problems of GNU Autoconf build migration are not CMake's fault. They will happen anytime one moves from a Unix-centric build culture to a truly cross-platform Unix / Cygwin / MinGW / MSVC build culture. Because Autoconf doesn't handle MSVC, builds typically have a completely different build system for MSVC. This often means the internals of the application have diverged, as was in the case of Chicken. Different pathnames, different shell assumptions, different quoting problems, etc. Getting an app to be truly cross-platform is a lot of gruntwork. This is why I'm askance about some of the suggestions, like name canonization, being a big improvement to CMake's future. Yes they'll help, any good incremental design will help, but strategically it's just not the core problem one faces when unifying a build. The reason some Unix guys won't budge, has nothing to do with whether CMake is a better tool than Autoconf. It's because going truly cross-platform to Unix / Cygwin / MinGW / MSVC has no value to them, and represents tons of gruntwork. I would like to know in the case of PLplot, how mature the Unix / Cygwin / MinGW / MSVC builds already were. Did they all essentially work already? Were they all well supported and tested? Were the app internals essentially similar for all platforms, handling pathname conventions gracefully and so forth? If all these things are true, then that's a great app to CMakeify. If I could cherry pick what apps to go after and convert, that's the sort of app I'd go for, because CMake would ride the coattails of a bunch of build work that's already been done. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
On 2006-11-18 10:16-0800 Brandon J. Van Every wrote: I would like to know in the case of PLplot, how mature the Unix / Cygwin / MinGW / MSVC builds already were. Did they all essentially work already? Under autotools, Linux and Mac OS X were fine, other Unices were untested. Cygwin and MinGW/MSYS worked reasonably well (I believe everything worked but dynamically loaded plug-in devices), but that took a dedicated effort (for example, a patch to libtool that was accepted by that team to correct bugs in shared library support for MinGW/MSYS a year or so ago). Our bare windows (i.e, windows without Cygwin or MinGW/MSYS) build was done with a completely different home-brew build system which provided a PLplot that was far from full featured. (I think just the core static library + examples, but Arjen may correct me.) Were they all well supported and tested? Were the app internals essentially similar for all platforms, handling pathname conventions gracefully and so forth? No and no. PLplot was far from perfect on windows. Arjen and one other windows developer have had to work to get shared libraries to work on windows with CMake since the home-brew windows build system only dealt with the static case. But they persevered (with some extremely useful help from this list on export and import DLL questions). Our windows platform is still not completely full-featured, but it has many more features (plotting devices, language front-ends, etc.) than it did before on windows which is why we are making a development release a week from today. We will follow that with other development releases with the eventual goal of completing the PLplot feature set (e.g., finally getting the plug-in version of our plotting devices to dynamically load) on windows. BTW, all the PLplot developers are volunteers who work on the package in their spare time and there are difficulties with the availability of open-source libraries on windows which I have alluded to before. For example, libltdl is missing so we are going to CMakeify the libltdl build (following advice given previously on this list from the KDE developers) to allow us to dynamically load the plug-in version of our devices. This is why it will probably take at least several more months to complete our feature set on windows. I guess the real reason the CMake has worked out so well on PLplot is we have a mix of developers who are extremely encouraging and tolerant about each other's (Linux or Mac OS X or windows) platform needs. I don't think our attitude is particularly unique in the free software world. For example, I presume this attitude is also the norm for the KDE project. In our own case, I belong to a very small minority of developers in the world who have never had any windows experience (moved to Unix in the 80's, and Linux in the 90's with no MS detours), but I was fully aware of our windows developer's long-term difficulties with improving our home-brew windows build system. Thus, one of my motivations for giving CMake a try in July was it had potential to solve the windows build limitations that existed back then. The rest is history; our windows developers have taken great advantage of that opportunity as I have cheered them on from the sidelines. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
Hi Brandon, Von: Brandon J. Van Every [EMAIL PROTECTED] ... Then, I read the article (http://lwn.net/Articles/188693/) by Alex on KDE's switch from autotools to cmake. That article really resonated with me (especially the remarks about simple CMake syntax which every developer would find it easy to understand) so I presented the possibility to the PLplot development list of moving to a CMake build system. However, I got the if it ain't broke, don't fix it standard reaction that Brandon noted above. Fortunately, I ignored that reaction. One of the advantages of trying out CMake for an autotoolized project is the two build systems can coexist peacefully. Also, as Brandon noted the CMake syntax is really easy to learn so you can quickly show some results. So all it really takes to start the move to cmake is just for one catalyst developer for a project to be convinced enough to make a start. I was that catalyst guy for PLplot. I started in early July soon after Alex's article came out. I soon had a proof-of-concept CMake build for one of our simpler libraries, Getting started with CMake is easy. It lulls people into a false sense of security about the amount of work involved... which from a CMake promotion standpoint, is a good thing. I'm cynical about what it takes to *finish* such jobs. In the absence of money, I wouldn't undertake it again. Why ? What was that hard ? For me, getting the RPATH stuff was hard (since I didn't understand RPATH at all before this), finding a way to detect Qt4 so that it works for everybody was hard and doing the automoc stuff which KDE developers are used to was hard. Beside that, once I understood how generating sources during the build work, there where no big problems. Just a *lot* of work, where Laurent Montel did a huge job, I mean, we have millions lines of code. Said that, one year earlier this wouldn't have been possible, since at that time the then newly introduced non-recursive makefile generator still needed some time to mature. In the beginning there was basically nobody on my side, we started with scons. This didn't work out, so David (one of our core developers) gave me the go to try my luck with cmake. I did that and today I'm the buildsystem maintainer. Not sure I'm happy about this ;-) Bye Alex -- Ein Herz für Kinder - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht! ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
Alan W. Irwin wrote: Our windows platform is still not completely full-featured, but it has many more features (plotting devices, language front-ends, etc.) than it did before on windows which is why we are making a development release a week from today. It sounds like Chicken and PLplot were at comparable levels of Windows support when they each started switching to CMake. Unix-oriented, hand crafted builds exist for Windows, they sorta work but tend to break, not all features available on the Windows side. it will probably take at least several more months to complete our feature set on windows. I'm guessing your initial snowball is a function of project size. More developers, so if more people get turned on to CMake, they can do more. Smaller projects only end up with 1 guy doing most of the work. This is also true of larger projects when political buy-in is absent. Anyways, I hope you can maintain momentum with CMake and Windows as you *finish* the cross-platform unification. I've done it; I have the perspective of having done it. I wonder if projects like yours will tend to chug through to the end, or whether they'll encounter late-term frustrations that slow or halt the progress. A lot of this is application dependent; if there had been much more to fix in Chicken, I may have given up. Political difficulties also ensue in the end game. At that point, development shouldn't be driven by Autoconf anymore. But, the Autoconf guys are used to their standard drill, and they persist. Similarly, the Linux guys are used to their Linux drill and not the newfangled Windows stuff. In the worst case, the old guard drives the old system forwards with lots of new features, making more bugs for CMake and / or Windows than you can fix. At that point, one puts one's foot down and says, Are you moving on with the new CMake build or not? It worked out ok in Chicken's case, but for a time I was worried that the work could end up being all for nothing. I guess the real reason the CMake has worked out so well on PLplot is we have a mix of developers who are extremely encouraging and tolerant about each other's (Linux or Mac OS X or windows) platform needs. I don't think our attitude is particularly unique in the free software world. For example, I presume this attitude is also the norm for the KDE project. In our own case, I belong to a very small minority of developers in the world who have never had any windows experience (moved to Unix in the 80's, and Linux in the 90's with no MS detours), but I was fully aware of our windows developer's long-term difficulties with improving our home-brew windows build system. Thus, one of my motivations for giving CMake a try in July was it had potential to solve the windows build limitations that existed back then. The rest is history; our windows developers have taken great advantage of that opportunity as I have cheered them on from the sidelines. Helps also to have multiple motivated Windows developers. In Chicken's case I was the only one. John Cowan came along later, but he guns on Cygwin, and I don't feel that exactly counts. Porting to native Windows means getting things to work on MSVC and MinGW. That said, his Cygwin testing definitely improved the CMake build, so the Cygwin aficionados are definitely useful to the overall enterprise. Also, he was useful for advocating *CMake*, whether or not he cared about native Windows stuff. The two problems, Autoconf -- CMake and Unix -- Windows are entwined in each other, but they are also distinct. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
Alexander Neundorf wrote: Hi Brandon, Von: Brandon J. Van Every [EMAIL PROTECTED] Getting started with CMake is easy. It lulls people into a false sense of security about the amount of work involved... which from a CMake promotion standpoint, is a good thing. I'm cynical about what it takes to *finish* such jobs. In the absence of money, I wouldn't undertake it again. Why ? What was that hard ? Yes, and I almost got evicted crossing the finish line. It's not a pattern I can continue. If anyone has some inspiring words of wisdom on how to consult CMake build migration skills, now would be the time to utter them. :-) For me, getting the RPATH stuff was hard (since I didn't understand RPATH at all before this), finding a way to detect Qt4 so that it works for everybody was hard and doing the automoc stuff which KDE developers are used to was hard. Beside that, once I understood how generating sources during the build work, there where no big problems. Just a *lot* of work, where Laurent Montel did a huge job, I mean, we have millions lines of code. Chicken is a smaller project (75K LOC) with smaller numbers of people working on it (primarily Felix). Difficulties scale down: it was *lots* of work for me, mostly single-gunning on the CMake build. Said that, one year earlier this wouldn't have been possible, since at that time the then newly introduced non-recursive makefile generator still needed some time to mature. In the beginning there was basically nobody on my side, we started with scons. This didn't work out, so David (one of our core developers) gave me the go to try my luck with cmake. I did that and today I'm the buildsystem maintainer. Not sure I'm happy about this ;-) I wrote something good enough that I could hand it off to others. Quite feasible for a 75K LOC project. I don't lose sleep about whether I'll be around in the future; the project doesn't strictly require me anymore. I can get hit by a truck and Chicken will still be moving along with CMake. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
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.
We can reduce migration time by simply providing a very nice and simple
API for building software using CMake, and the first step 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)...
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
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.
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})
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 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...
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)??
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
--
Tanguy Krotoff [EMAIL PROTECTED]
http://openwengo.org
ow_create_shared_library(curl)
ow_use_private_libraries(
OPENSSL
)
ow_add_public_include_dirs(
${CMAKE_CURRENT_SOURCE_DIR}/include
)
ow_add_private_include_dirs(
${CMAKE_CURRENT_SOURCE_DIR}/lib
)
ow_add_private_definitions(
-DBUILDING_LIBCURL
-DCURL_DISABLE_FILE
-DCURL_DISABLE_LDAP
-DCURL_DISABLE_DICT
-DCURL_DISABLE_TELNET
-DCURL_DISABLE_TFTP
-DUSE_SSLEAY
-DUSE_OPENSSL
)
if (APPLE)
find_package(ZLIB REQUIRED)
ow_use_public_libraries(
ZLIB
)
endif (APPLE)
if (WIN32)
ow_add_private_libraries(
ws2_32
winmm
)
endif (WIN32)
ow_add_sources(
lib/base64.c
lib/connect.c
lib/content_encoding.c
lib/cookie.c
#lib/dict.c
lib/easy.c
lib/escape.c
#lib/file.c
lib/formdata.c
lib/ftp.c
lib/getenv.c
lib/getinfo.c
lib/gtls.c
lib/hash.c
lib/hostares.c
lib/hostasyn.c
lib/hostip.c
lib/hostip4.c
lib/hostip6.c
lib/hostsyn.c
lib/hostthre.c
lib/http.c
lib/http_chunks.c
lib/http_digest.c
lib/http_negotiate.c
lib/http_ntlm.c
lib/if2ip.c
lib/inet_ntop.c
lib/inet_pton.c
lib/krb4.c
#lib/ldap.c
lib/llist.c
lib/md5.c
lib/memdebug.c
lib/mprintf.c
lib/multi.c
lib/netrc.c
#lib/nwlib.c
lib/parsedate.c
lib/progress.c
lib/security.c
lib/select.c
lib/sendf.c
lib/share.c
lib/speedcheck.c
lib/sslgen.c
lib/ssluse.c
lib/strequal.c
lib/strerror.c
lib/strtok.c
lib/strtoofft.c
#lib/telnet.c
#lib/tftp.c
lib/timeval.c
lib/transfer.c
lib/url.c
lib/version.c
)
ow_create_binary()
ow_create_static_library(gaim)
ow_use_public_libraries(
GLIB2
)
ow_add_public_include_dirs(
${CMAKE_CURRENT_SOURCE_DIR}/include
${CMAKE_CURRENT_SOURCE_DIR}/src/libgaim
)
ow_add_private_include_dirs(
Re: [CMake] Suggestion for CMake platform/compiler detection
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
Re: [CMake] Suggestion for CMake platform/compiler detection
On 2006-11-17 16:56-0800 Brandon J. Van Every wrote: 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. Brandon, I largely agree with many of the things you said in the rest of your post, but let me add my Linux-loving Autoconfer PLplot experience which is different than your generalization above. In short, we weren't in a lot of pain from autotools, but we still made the switch to CMake because we did have some concerns about autotools, the combined power of many developers made the switch really easy, and we had two starting catalysts (Alex's article and me). Here are the details. PLplot has a fairly complicated build consisting of a few core libraries, several language interfaces to those libraries, a large number of plotting device plug-ins, and an extensive docbook-based documentation build. To do all these build tasks, PLplot has used a nicely organized autotooled build for some time which took several years to fully develop. However, although I was largely comfortable with autotools and was probably the second-ranked autotools expert amongst our developers it bothered me that three different syntaxes (especially m4 which I really dislike for autoconf, but also automake and libtool syntax) were required, that any extension of PLplot always seemed to involve quite a bit of autotools work, and that the fundamental changes in autoconf, automake, and libtool that kept occurring meant we had to keep changing our configuration files in magical ways. For example, earlier this year I tried a preliminary version of libtool-2 to see whether that fixed some fortran issues, and it took help by a guru on the libtool list (making what seemed like an arbitrary reordering of our configuration) to get our build to work with that newer version of libtool. That help was much appreciated, but still the necessity for that help and the other factors I have mentioned made me uneasy about continuing to depend on autotools. Then, I read the article (http://lwn.net/Articles/188693/) by Alex on KDE's switch from autotools to cmake. That article really resonated with me (especially the remarks about simple CMake syntax which every developer would find it easy to understand) so I presented the possibility to the PLplot development list of moving to a CMake build system. However, I got the if it ain't broke, don't fix it standard reaction that Brandon noted above. Fortunately, I ignored that reaction. One of the advantages of trying out CMake for an autotoolized project is the two build systems can coexist peacefully. Also, as Brandon noted the CMake syntax is really easy to learn so you can quickly show some results. So all it really takes to start the move to cmake is just for one catalyst developer for a project to be convinced enough to make a start. I was that catalyst guy for PLplot. I started in early July soon after Alex's article came out. I soon had a proof-of-concept CMake build for one of our simpler libraries, and the whole project quickly snowballed with all our active developers soon starting to contribute to our CMake build system. The result is that one week from now we plan to make a PLplot release featuring the new CMake build system. This new build system is already a significant improvement on our old autotools-based and separate windows-based build systems and is generating significant additional PLplot developer activity because CMake is so easy to work with. I think it is fair to say this project succeeded beyond the wildest dreams I had in July when I started it. This example of how CMake has quite casually taken over one autotoolized project reflects in my opinion the fact that we live in a chaotic world where small positive actions often have large positive consequences. So in such a world careful planning, discussion, and paying attention to nay-sayers (who automatically always claim you have not done your planning carefully enough) can actually be counterproductive time wasting. Instead, my advice is to take small positive actions (show them the code) to see what might happen whenever you have the opportunity to do so, and always try to identify nay-sayers (those who seem to get a kick out of always being negative) and ignore what they say :-) In my case, that casual try and see tactic paid off big-time with a great new build system for PLplot, and I think there are lots of others in the free software world who are following a similarly casual path to CMake. The result is that CMake mindshare is rapidly increasing. Of course, great articles like that written by Alex also have a large catalytic effect. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Re: [CMake] Suggestion for CMake platform/compiler detection
Alan W. Irwin wrote: [The Autotools] help was much appreciated, but still the necessity for that help and the other factors I have mentioned made me uneasy about continuing to depend on autotools. Yes, the Autotools have many liabilities. Most notably, they are built in layers, all with different design requirements and beholden to different legacy issues. It makes some things impossible to accomplish; one simply has to accept the known workarounds. The Autotools docs are evolved enough, that the workarounds are actually in the docs Then, I read the article (http://lwn.net/Articles/188693/) by Alex on KDE's switch from autotools to cmake. That article really resonated with me (especially the remarks about simple CMake syntax which every developer would find it easy to understand) so I presented the possibility to the PLplot development list of moving to a CMake build system. However, I got the if it ain't broke, don't fix it standard reaction that Brandon noted above. Fortunately, I ignored that reaction. One of the advantages of trying out CMake for an autotoolized project is the two build systems can coexist peacefully. Also, as Brandon noted the CMake syntax is really easy to learn so you can quickly show some results. So all it really takes to start the move to cmake is just for one catalyst developer for a project to be convinced enough to make a start. I was that catalyst guy for PLplot. I started in early July soon after Alex's article came out. I soon had a proof-of-concept CMake build for one of our simpler libraries, Getting started with CMake is easy. It lulls people into a false sense of security about the amount of work involved... which from a CMake promotion standpoint, is a good thing. I'm cynical about what it takes to *finish* such jobs. In the absence of money, I wouldn't undertake it again. and the whole project quickly snowballed with all our active developers soon starting to contribute to our CMake build system. Your dynamics are different because you got a snowball effect. What if you hadn't? What if you had been the only guy stuck with working on the build? There aren't enough developers working on the Chicken Scheme build to get any kind of snowball effect. Basically there's myself, Felix, and occasional patches from people who notice things that are wrong. I didn't get any snowball, I just trundled away for a long time. What I did get, however, was the buy-in of the principal author. So that with sufficient elbow grease, I could ensure that CMake would be the future and not Autoconf. So yes there's a future in CMake migrations, *if* you have the manpower to make the transitions. I'd like to get automated Dashboard testing going for Chicken, but I don't want to lead it the way I led the build. Every time I bring this sort of thing up, crickets chirp. And, I'm quite sure there's a quorum of Chicken developers who actually care about automated testing. But nobody wants to do the work. I wonder if this is all simply a function of project size, longevity, and the social relationships that are bred / culled from projects that survive a long time. The result is that one week from now we plan to make a PLplot release featuring the new CMake build system. This new build system is already a significant improvement on our old autotools-based and separate windows-based build systems and is generating significant additional PLplot developer activity because CMake is so easy to work with. I think it is fair to say this project succeeded beyond the wildest dreams I had in July when I started it. This example of how CMake has quite casually taken over one autotoolized project reflects in my opinion the fact that we live in a chaotic world where small positive actions often have large positive consequences. So in such a world careful planning, discussion, and paying attention to nay-sayers (who automatically always claim you have not done your planning carefully enough) can actually be counterproductive time wasting. Instead, my advice is to take small positive actions (show them the code) to see what might happen whenever you have the opportunity to do so, and always try to identify nay-sayers (those who seem to get a kick out of always being negative) and ignore what they say :-) I would have never undertaken the Chicken Scheme build without Felix's buy-in as a prerequisite. It sounds like you had some authority to make things happen in the PLplot project. Or at least, your findings would likely be taken seriously by a core group of programmers who knew your work. Not everyone is in that position. Not everyone coughs up the initial labor either. It would be useful to track the status of CMake-ifying projects, to see who thrives and who dies out. For the record, I crossed the finish line, then the proverbial medics carried me away on a stretcher. I'm strictly in maintenance
Re: [CMake] Suggestion for CMake platform/compiler detection
Bill Hoffman wrote: The problem with the shell, is that you can run cmake, then run make from a different shell For the most part that works on unix. zsh, bash, sh, csh basically work the same. The trouble shows up on windows. Yep, open source on Windows is nothing but TROUBLE. It doesn't get the testing, consistency, or packaging of the Linux universe. Really only the Cygwin stuff is reliable for prime time, and with that you get shafted with the GPL, typically. -mno_cygwin is possible in theory, but breaks builds in practice, and is never the default for the huge stacks of Cygwin libraries people use. The point of packaging is to spare people the pain of building things that don't quite build right, so that stuff actually works. It also turns off a lot of the Unix compatibility, so a lot of things simply won't build. The bottom line is, if you want to do open source and don't want to get stuck with the GPL, you have to build lotsa things from scratch and they tend to break. MSYS uses a version of bash, and MinGW uses the windows shell, and cygwin uses bash, zsh, or some other more like unix. Pedantically: MinGW doesn't use a shell. MinGW is a compiler that could be run under straight Windows command prompt, under MSYS, or some perverts even run it under the Cygwin bash shell. Also a few weirdos like myself, who find MSYS's Autoconf support to be completely broken, use a nonstandard bash shell for MSYS instead of the default rxvt. http://sourceforge.net/projects/mingw-install really saved my bacon on some legacy Autoconf build issues I was having. So, I think shell identification is quite valuable. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
On 2006-11-16 13:00-0800 Brandon J. Van Every wrote: Bill Hoffman wrote: The problem with the shell, is that you can run cmake, then run make from a different shell For the most part that works on unix. zsh, bash, sh, csh basically work the same. The trouble shows up on windows. Yep, open source on Windows is nothing but TROUBLE. It doesn't get the testing, consistency, or packaging of the Linux universe. Really only the Cygwin stuff is reliable for prime time, and with that you get shafted with the GPL, typically. The subscribers to this mailing list are a mixture of windows and Linux developers who normally get along wonderfully well. We each have different belief systems though, so could you please turn down the off-topic rhetoric that is offensive to one side? There is nothing wrong with saying Cygwin has a lot of GPLed packages (like Linux itself), but to go beyond that with your opinion about the GPL is off-topic. I have no windows experience so I try not to say much about it, but from what the PLplot windows developers tell me there are problems in building and finding the appropriate versions of all libraries required by PLplot (and presumably other Linux software as well which tends like PLplot to use a wide variety of libraries). So I will go along with your first sentence quoted above to that limited extent. I presume though that as cmake becomes more ubiquitous in the Linux world (and from all I can tell that is happening fast) there will be a concerted effort to port more of our useful libraries to windows, and the problem of library availability on windows for software that originated on the Linux platform should be greatly reduced in consequence. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
Alexander Neundorf wrote: so did OpenWengo now officially switch to CMake ? Yes we are switching, still some minor work to do I end up creating a framework (set of macros) above CMake that simplifies the writing of CMakeLists.txt (we have more than 100 CMakeLists.txt) + adds some features http://dev.openwengo.org/trac/openwengo/trac.cgi/wiki/OWBuild -- Tanguy Krotoff [EMAIL PROTECTED] http://openwengo.org ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
Alexander Neundorf wrote: CMake has some of that. It has for OS: UNIX APPLE WIN32 CYGWIN MINGW Cygwin is not an OS, it's a compiler. The Bash that comes with Cygwin provides a filesystem environment. Oftentimes when people compile on Windows in open source land, what they really want / need to know is the difference between various shells. Is it Cygwin Bash, MSYS Bash, straight Windows Command Prompt, or something else? And for the compilers: Not sure it has GCC, but at least it has CMAKE_COMPILER_IS_GNUCXX BORLAND MSVC For the Intel Compiler in KDE we currently check using if(CMAKE_C_COMPILER MATCHES icc) So there is room for improvement. There's coverage, it's just ad hoc, not canonized, and has an inconsistent interface. At present this doesn't trouble me, personally. I think mainly some of the cmake files in Modules/ and Modules/Platforms/ would have to be extended. For compatibility reasons I'm not sure new prefixes like OS_ and CC_ would be a good idea. It would also be good to look at other canonical (OS compiler library etc.) specifiers before deciding on such a thing. Like the Boost conventions, for instance. I do think any canonization should include space for a shell specifier, and I don't think any extant canonization does that. Shells are *exceedingly* problematic for builds. Can't tell you how much time I've lost to backslash, escaped whitespace, and double quoting issues. You know already which sentence follows next... ;-) Feel free to send a patch :-) Or at least just file a feature request. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
Brandon J. Van Every wrote: Alexander Neundorf wrote: CMake has some of that. It has for OS: UNIX APPLE WIN32 CYGWIN MINGW Cygwin is not an OS, it's a compiler. The Bash that comes with Cygwin provides a filesystem environment. Oftentimes when people compile on Windows in open source land, what they really want / need to know is the difference between various shells. Is it Cygwin Bash, MSYS Bash, straight Windows Command Prompt, or something else? And for the compilers: Not sure it has GCC, but at least it has CMAKE_COMPILER_IS_GNUCXX BORLAND MSVC For the Intel Compiler in KDE we currently check using if(CMAKE_C_COMPILER MATCHES icc) So there is room for improvement. There's coverage, it's just ad hoc, not canonized, and has an inconsistent interface. At present this doesn't trouble me, personally. I think mainly some of the cmake files in Modules/ and Modules/Platforms/ would have to be extended. For compatibility reasons I'm not sure new prefixes like OS_ and CC_ would be a good idea. It would also be good to look at other canonical (OS compiler library etc.) specifiers before deciding on such a thing. Like the Boost conventions, for instance. I do think any canonization should include space for a shell specifier, and I don't think any extant canonization does that. Shells are *exceedingly* problematic for builds. Can't tell you how much time I've lost to backslash, escaped whitespace, and double quoting issues. The problem with the shell, is that you can run cmake, then run make from a different shell For the most part that works on unix. zsh, bash, sh, csh basically work the same. The trouble shows up on windows. MSYS uses a version of bash, and MinGW uses the windows shell, and cygwin uses bash, zsh, or some other more like unix. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestion for CMake platform/compiler detection
Hi Tanguy, Von: Tanguy Krotoff [EMAIL PROTECTED] so did OpenWengo now officially switch to CMake ? Hi Cmake supports several boolean for platform/compiler detection: UNIX APPLE WIN32 CYGWIN MINGW BORLAND I think this approach is too simple and not very easy for the developer. What about code that I want to compile under Windows using Borland, Intel, MinGW and MSVC? What about code compiled under Cygwin? IF (UNIX) is true or not? What about Intel compiler under UNIX? A good and simple approach is to totally separate platform OS detection from compiler detection. I see something like this: Operating systems: - OS_WINDOWS - OS_WIN32 ... Compilers: - CC_MSVC (Microsoft Visual C++) - CC_MSVC6 (Visual C++ 6) ... Qt as the same approach and I think Qt is a good example of a massively multiplatform tool. See qglobal.h at: http://doc.trolltech.com/3.3/qglobal-h.html It would be good for CMake to have the same separation between OS and compiler detection, what do you think? CMake has some of that. It has for OS: UNIX APPLE WIN32 CYGWIN MINGW And for the compilers: Not sure it has GCC, but at least it has CMAKE_COMPILER_IS_GNUCXX BORLAND MSVC For the Intel Compiler in KDE we currently check using if(CMAKE_C_COMPILER MATCHES icc) So there is room for improvement. I think mainly some of the cmake files in Modules/ and Modules/Platforms/ would have to be extended. For compatibility reasons I'm not sure new prefixes like OS_ and CC_ would be a good idea. You know already which sentence follows next... ;-) Feel free to send a patch :-) Bye Alex -- Ein Herz für Kinder - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht! ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
