On Wed, Oct 08, 2008 at 01:14:28PM -0400, Bill Nottingham wrote: He said F-11. I would extrapolate that to mean "branch libtool for F-10 now, and have devel be libtool 2.2.x." That would have no bearing on rawhide/F-10. josh

Karsten Hopp wrote: It doesn't need FESCo approval. It does need discussion, wide publication, and possibly an offer to help packagers who are affected by the change. A wiki page is definitely a good place to start. If you feel the change is too disruptive to land in the main repo until some things have been fixed (even in the earliest period of the F-11 rawhide cycle) you can coordinate with rel-eng to have a separate build tag where you work on fixing the packages that break before turning it loose on the masses. -Toshio

On Wed, 2008-10-08 at 19:36 +0200, Karsten Hopp wrote: Isn't the whole point of libtool that it should make things _easier_, not break huge swathes of packages whenever we change it? How about we fix those 300 packages by making them _not_ use libtool, rather than making them use the latest version? -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation

On Fri, 2008-10-10 at 11:31 -0700, Toshio Kuratomi wrote: The state of the art is "gcc -shared". - ajax

On Fri, 2008-10-10 at 12:07 -0700, Toshio Kuratomi wrote: Sun cc is pretty similar, but solaris has gcc installed well over half the time anyway. *BSD and OSX are all gcc, Windows is effectively gcc for open source projects, and there are no other operating systems. Most of the complexity in libtool (and autotools in general) is to support systems that simply are not worth supporting and that practically speaking don't exist anymore. I'm being slightly flip in saying 'gcc -shared' but really not by much. Honestly for any fringe platform the correct thing to do is port gcc/binutils/gmake first. - ajax

2008/10/10 Adam Jackson <ajax(a)redhat.com&gt;: That's noble and all, but in the meantime I tend to like relying on the years of experiences built into libtool. Taken a look at mesa's bin/mklib lately? Tell me if you ever want to work on something like that. You may have noticed how dolt doesn't touch the linking part of libtool at all. Something that people seem to forget about when bashing libtool is all the flexibility it offers. Like convenience libraries? Like easily deciding if you want static or shared libraries? Like having your programs work while their in the source tree? Like having your so version and symlinks handled automatically? -- Dan

On Fri, 2008-10-10 at 15:24 -0400, Adam Jackson wrote: Though these beasts are GCC variants, they actually are quite different from Linux-vendor's GCCs or FSF GCC. Ouch! Supporting different compilers is very small detail in libtool (and the autotools in general). They do a lot more. Ralf

On Fri, Oct 10, 2008 at 02:51:17PM -0400, Adam Jackson wrote: Not so much if you're trying to build for windows. The mingw32 work has only been made viable because libtool has basically taken care of the horrible shared library build process required by Windows. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Fri, Oct 10, 2008 at 03:40:49PM -0400, Adam Jackson wrote: Traditionally the problem has been that you actually need to generate two different bits of the DLL. A runtime part and linktime part. I thought it was still the case that you needed to generate these separately, but it seems the libtool docs I was reading are outdated, because the build logs I'm looking at show it does in fact appear to do everything in one go with -shared. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Fri, Oct 10, 2008 at 09:38:22PM +0000, Kevin Kofler wrote: [extremely insightful stuff] Kevin, we'd really like you as part of the MinGW project ... I'll take a look at the updated NSIS package you sent on Monday. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v

On Fri, Oct 10, 2008 at 02:51:17PM -0400, Adam Jackson wrote: That doesn't work on MinGW though. I don't really like libtool (who does?) but it does solve a certain problem properly. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

On Fri, 2008-10-10 at 11:31 -0700, Toshio Kuratomi wrote: CMake! Catch the wave! http://www.cmake.org/

On Fri, 2008-10-10 at 15:56 -0400, Braden McDaniel wrote: Why the h8? He was speaking in the context of "the state of the art" and in my oh-so-humble opinion CMake is it. The whole of the Autotools stack is very much... not. Last I checked I was just some random guy on the internet who has sadly not been granted the power to force anyone to do anything. There, does changing the subject make you happier?

Callum Lerwick <seg <at> haxxed.com> writes: +1 The suggestion to convince the automake developers to use something other than libtool is pointless, because automake should also go away, it's at least as obsolete, buggy, unable to maintain backwards compatibility, annoying, a massive time waster at build time and a major PITA for developers to code with as libtool is. The whole autotools stack sucks. It always did, we just didn't have anything better. We now do, so why are people still using autotools? Some of the major design failures of the autotools: * They work by copying the same sets of files into lots of programs and encourage distributing generated files (and break compatibility so often that that recommendation is almost always followed), so we end up with dozens of programs all having their own copy of the check for some library - if it's broken, all those programs need patching (and aclocal is a bad solution to that because it involves more pregenerating and copying). A modern build system like CMake centralizes the checks so there's just one copy to fix (just like shared libraries) and keeps compatibility so programs can rely on a compatible version of the build tool to just be there and not ship pregenerated files. * They're supposed to make programs more portable, but use *nix-only shell scripts. (And horribly ugly shell scripts working around bugs in dozens of subtly incompatible shells (all claiming to be Bourne-compatible and/or POSIX-compliant) at that.) * Libtool generates .la files even on platforms which don't need them. It's ridiculous that we still have to delete unwanted files in almost all packages, and even more so that they have a comment on the top saying "DON'T DELETE THIS FILE!". (That said, CMake has a similar dependency tracking feature which, when enabled, is similarly broken by default. A package has to either not use dependency tracking at all (which may cause problems on some platforms/configurations, e.g. static libraries) or use an extra command to do the right thing (only linking in indirect deps explicitly if the platform requires it). But at least it's possible, unlike libtool where you have to manually delete a file which screams not to be deleted.) * Autoconf defaults (and it's extremely hard to disable that, IIRC you can't use some convenient macros almost all programs use and have to use low-level stuff) to doing all sorts of useless checks as part of the checks that the build environment is "sane", such as: - checking that ISO C90 (ANSI C89) headers exist (hello??? It's 2008! That standard is 18-19 years old now! What totally obsolete systems _still_ not supporting them do we want to support?), the results of which are generally thrown away (because the program just assumes the ISO C headers exist, and rightfully so, and thus doesn't do anything with the HAVE_FOO variables from those tests), or - checking that the Fortran and Java-to-native-code compilers exist (even in an all-C/C++ project). All those totally useless tests waste a lot of time for every single build, even of trivial projects. * Automake has 2 modes, a GNU mode which enforces GNU guidelines and a "foreign" mode which doesn't, but for some insane reason, it defaults to the GNU mode. This is broken for many reasons: - A tool should not error when some coding style guideline is broken, at most it should warn. - Most projects using automake these days are NOT GNU projects, it's silly to try to enforce GNU's guidelines on those. - The most annoying thing the "GNU" mode enforces is the presence of some files like COPYING (OK, this one makes sense, though IMHO License.txt is a better name, we're no longer in the 1980s), INSTALL (which is often a verbatim copy of the default GNU INSTALL document added just to make automake happy and thus completely and utterly useless), NEWS and AUTHORS (both often completely empty, added just to make automake happy) and with these obsolete (the days of systems allowing only 7 characters in a file name are long gone!), non-portable names (Window$ users expect .txt extensions, and even on GNU/Linux, these days, the extensionless names aren't always properly detected as text files). * Libtool thinks /usr/lib64 needs an RPATH, unless you use a Fedora-patched version, in which case it'll think /usr/lib needs an RPATH on x86_64 even on a Debian system. So, unless you're about to hack the generated/copied libtool scripts manually, there's no way (using libtool) to make a package which will generate no bogus RPATHs on x86_64 on at least one distro. Needless to say, CMake doesn't have the above shortcomings (except for dependency tracking, and even that can be made to do the right thing by the library project if they know what they're doing; and if they don't know what they're doing, they'll probably not bother generating a dependency file at all ;-) - CMake doesn't do that by default). CMake also has cool features like reporting the progress percentage of builds during make. And it's way faster too. Kevin Kofler

Braden McDaniel wrote: That's it, I'm hereby invoking Wayne Lord of the Malted Beverages to have y'all banned to heck :-)

On Sat, 2008-10-11 at 00:44 +0000, Kevin Kofler wrote: And once again you miss the point: changing packages' build systems wholesale is *never* going to be the right thing for Fedora to do. Promoting a particular build system for participation in such a task is not "long term planning", it's noise. If you really care about getting projects to switch to CMake, swim upstream. -- Braden McDaniel e-mail: <braden(a)endoframe.com&gt; <http://endoframe.com> Jabber: <braden(a)jabber.org&gt;

Dan Nicholson <dbn.lists <at> gmail.com> writes: Indeed, I'm glad you folks are aware there's a problem and trying to fix it. And that's good news, one less annoyance, thanks for that! It may have been a bug, but what I described is exactly what Romain Liévin and I experienced with the tilibs (the libti* stuff at http://svn.tilp.info/ ): if Romain autotooled the project on Debian, I ended up with rpaths on Fedora x86_64, if I autotooled it on Fedora, he ended up with rpaths on Debian x86_64. If libtool 2.2 does the right thing there, that's indeed good news. Kevin Kofler

On Sat, 2008-10-11 at 01:20 +0200, Lennart Poettering wrote: +1 I share this view. Cmake is imake in new clothes and suffers from the same design flaws as imake did. It's only the limited set of requirements being used by the limited set of use cases it's proponents apply which lets them think "cmake is better". Ralf

On Sun, Oct 12, 2008 at 11:44 AM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote: Ok the problem is that build tools are one of the things developers build strong relationships with (System administrators build it with their mail handler tools). You point out the deficiencies in someones choices of tools and the brain begins attack/flight/protect hormone chains. The same emotional centers in the brain as if you had picked up an axe and pointed it at someones family. The hormones get triggered and all logic circuits are cut off until the testosterone and serotonin get back down to lower levels. [I think its serotonin.. it may be one of the other brain chemicals that get fired off in big numbers when this occurs.] The best part of this is that your logical parts of your brain are 'tricked' into saying "This is the most logical thing to do" although 3 or 4 days later you might regret it (though reading past emails will probably trigger the same chemical reactiosn and you wont disagree but even send one or two more emails to prove your point.) So basically this conversation is a 'dead' conversation. People have their hairs on their necks up, testosterone pumping to put 3 or 4 beards in a day, and are to the flinging poo part. At this point, there is no way either side is going to say that Cmake is better at this, or Autotools is better than that.. Wait a week, and see if one can bridge the gap with some diplomatic discourse. Yes diplomatic discourse uses a lot of soft words and will spend a week talking around the point before bringing it up.. but thats because its meant to get around the human brains stupidity. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"

2008/10/12 Callum Lerwick <seg(a)haxxed.com&gt;: No it actually doesn't assume that sadly. The psychology has mostly been studied in cars, but shows up in other choices also. A person may hate every Ford part/car they have gotten for the last 4 years and say it day in and day out, but ask them to switch to a Chevy/Toyota/etc and the same reaction can occur.. In fact for some people the reaction will be more active during such conversations because their brain has mapped extra loyalty to the tool to deal with the fact the tool has been failing or not doing what they want. There are differences in software but the general human brain is the same. It is built for survival against things that aren't as a big of concern for most people and uses those circuits to deal with things that on the evolutionary scale are small. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"

One specific problem with cmake again emerges because of Windows / "strange platform" portability. Gnulib[1] offers a very important option to us when porting software which makes lots of posix/libc calls. Unfortunately Gnulib doesn't currently work unless you're using automake & autoconf, and I cannot see that changing any time soon, since Gnulib is intimately tied to m4 macros. Rich. [1] http://www.gnu.org/software/gnulib/ -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/

I have to correct myself slightly about kdewin32: I wrote: Actually, it's not automatical, you do need to specify: include_directories(${KDEWIN32_INCLUDES}) like for any other library. And also: target_link_libraries(yourexecutable ${KDEWIN32_LIBRARIES}) (again, as for any other library). Kevin Kofler

Now how much does it take to use the "foreign" mode? Not much. Just the 7 letters: "f-o-r-e-i-g-n". That is not much of a pain, isn't it? :-) Cheers, Debarshi

On Fri, Oct 10, 2008 at 10:06 AM, David Woodhouse <dwmw2(a)infradead.org&gt; wrote: The amount of breakage is usually very minor. The big thing that caused breakage is that libtool-1.5 used to automatically haul in configuration for C, C++ and fortran. Certainly you've seen this in a configure run where it's checking for gcc, then g++, then g77. With libtool-2.2, you have to specify if you need more than C. See here: http://www.gnu.org/software/libtool/manual/libtool.html#index-LT_005fLANG-89 And an example patch where the package was broken using libtool-2.2: http://lists.freedesktop.org/archives/hal/2008-May/011730.html Pretty basic. I'm guessing someone could plow through and fix all these issues pretty quickly. Gentoo has already been doing this for months, so it would be straightforward to find any necessary patches. -- Dan

On Fri, Oct 10, 2008 at 05:20:30PM -0400, Braden McDaniel wrote: If I parse that correctly, are you saying that autoreconf *shouldn't* be run as part of an RPM build? I have found that it sometimes needs autoreconf if I patch the configure.ac script -- something which happens rather more frequently when porting to MinGW. (After these patches go upstream then it won't be a problem of course). Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

Dan Nicholson <dbn.lists <at> gmail.com> writes: And that's one of the main design flaws: * Bugs at one place get copied into hundreds of packages. * It wastes space for autogenerated files in tarballs (and those configure scripts can often be HUGE, e.g. anything including the KDE 3 acinclude.m4 ends up with a huge (over a MB) configure script). * It makes you reliant on the shell, which may be not available (Window$ - sure, there is MSYS, but having to install MSYS is no better than having to install e.g. CMake) or very buggy (some proprietary Unix systems, workarounds for which are littered all throughout the autotools). * It is unnecessary: Why is it OK to have to install make and not e.g. CMake? * It leads to non-reproducibility, i.e. programs which only build with generated files which are very hard to regenerate properly ("fragile" as you call it), which makes it harder to modify the programs (I've had my fair share of problems already with programs which were hard to modify because they depended on some ancient autotools version which was no longer available in current distributions - the lack of backwards compatibility is a real problem, using pregenerated files solves this problem only for users, not for developers), going against the spirit of Free Software, maybe even against the letter of the GPL. (CMake is only an example in the above - you could fill in any central build tool there, like SCons, qmake etc.) Unfortunately, I don't think all the problems caused by this design flaw can be fixed within the autotools. What I would suggest to you and other autotools developers (and that's a serious suggestion!) is: * improve backwards compatibility: Don't depend on pregenerated files for backwards compatibility, instead make sure there's a way to use older .ac and .am files with newer autotools. Keying compatibility features off macros like AC_PREREQ might work, or maybe something like Java's --source 1.5 (or 1.4 or ...) switch. * start discouraging shipping pregenerated files, instead make sure that autoreconf actually works (which mainly amounts to the above point about backwards compatibility). But unfortunately, this won't solve the problem of the reliance on the shell, and as configure.ac scripts can contain arbitrary shell snippets, this can't really be fixed without a major redesign, the result of which would effectively no longer be autotools. Kevin Kofler

Jens Petersen wrote: Maybe you can offer an alternative? And no, I don't mean reciting names of some hacks some cool kids may have put together for their birthday... And not something that requires me to install it first before I can build this tarball I downloaded. behdad

Conrad Meyer wrote: How about simply solving the problems the autotools solve and then some? -- Braden McDaniel e-mail: <braden(a)endoframe.com&gt; <http://endoframe.com> Jabber: <braden(a)jabber.org&gt;

Behdad Esfahbod wrote: CMake, but... ... this requirement is broken by design. As Conrad points out, you have to install tools such as GCC, Binutils and Make anyway, why not CMake? The perverse idea of allowing to build software using a certain build system without actually installing that build system in the main reason the autotools suck as much as they do. (It means relying on slow shell code which is really ugly because it has to work around bugs of various obscure systems' shells, and it means autogenerating files and passing them off as "source code".) Not to mention that a *nix shell is actually harder to install than a CMake binary on some systems. (Not all the world is a *nix.) How hard is it to "yum install cmake"? Kevin Kofler

Ralf Corsepius wrote: What FUD? There's an alternative which is: * easier to learn, * more portable, * more backwards-compatible (with its own previous versions), * faster, * generating nicer makefiles (progress percentages, color output), * designed in a better way (information is kept in central places instead of being copied into hundreds of projects), * used by more and more software, including big projects like KDE 4. It's called CMake. Kevin Kofler

On Wednesday 03 December 2008 01:31:20 am Ralf Corsepius wrote: Learning a new thing is always different. He's not telling you it's easier for *you* to learn something new than something *you* already know, but that it's easier for someone unfamiliar with autotools nor CMake to learn CMake than autotools. "FUD! FUD!" Agreed, but it's not like they get in the way. Reinvention of build-system-tools-in-general. Like a new version of autotools (they don't pretend to be backwards compatible). Uh, what? Regards, -- Conrad Meyer <konrad(a)tylerc.org&gt;

On Wed, 2008-12-03 at 11:04 +0100, Ralph Angenendt wrote: No, it's a badly formulated sentence. Should better have been something as "A tool with marginal importance outside of KDE".

On Wednesday 03 December 2008 02:21:10 am Ralf Corsepius wrote: What "new OS" has come out in the past 5 years or so that CMake doesn't already support? Saves resources on koji, if nothing less. Regards, -- Conrad Meyer <konrad(a)tylerc.org&gt;

Ralf Corsepius wrote: That's not true. Have you ever looked at the %cmake and %cmake_kde4 macros? How are they different from %configure? By being in cmake resp. kde-filesystem rather than redhat-rpm-config? That's just a Fedora packaging decision and it may change in the future, it has nothing to do with the build systems' design. Kevin Kofler

Ralf Corsepius wrote: Uh no, it doesn't. CMake: Configuration: cmake . or cmake .. Building: make Installing: make install/fast (or "make install" if you want it to do all the dependency checks the "make" step already did again like the autotools always do) Autotools: Configuration: ./configure or ../configure Building: make Installing: make install The only extra job the autotools have is the useless "autogenerate and/or files" (a.k.a. autoreconf) step, which is exactly the one I'm complaining about. Kevin Kofler

Ralf Corsepius wrote: Your reply is the FUD. ;-) Probably because you already learned the autotools, so you don't notice its learning curve anymore. Or you just haven't really tried CMake yet and so don't know how easy it is to get things done in it. The fact is, the autotools are a PITA to really understand. Things like: * when what file needs regenerating and/or gets automatically regenerated during make and why, * m4's arcane syntax, including considerations like when to quote things where, but also just the syntax itself (dnl for comments, [] for quoting etc.) and some other stuff work like black magic. (The first issue is also why the "autoreconf" sledgehammer, which got frowned upon earlier in this thread by some libtool developer(s), exists.) Then there's also the fact that there are too many tools: with CMake, you write all the definitions in one language/syntax, and it's up to you whether you want it all in one CMakeLists.txt or in several (e.g. one per directory, you can also have Find*.cmake files for library detection code, though those usually ought to be provided centrally, and finally you can also include any arbitrarily-named file). With the autotools, you have to provide at least 2 files (configure.ac and Makefile.am) with completely different syntax. And configure.ac itself is a mix of shell and m4. You also have to manually list all the makefiles to generate in configure.ac even if automake already knows about them, because autoconf doesn't. (Something I keep forgetting when I add a subdirectory to an autotools-using project.) How is it not portable? It works on all the major platforms and getting it to work on some obscure *nix system is fairly easy. As for non-*nix systems, good luck getting the autotools to work on those! They can't even cope with Window$ without workarounds like MSYS. CMake can be ported to basically anything which supports C++. And it's really more flexible than you think. You can call color output a "non-helpful gimmick" (though it really helps visually separating the lines just saying what is being built from any error or warning messages), but progress percentages are definitely useful! Do you not want to know how far your build actually is? It's not crack-ridden, it allows fixing any bugs in a single central place. It also saves disk space. And if you really need to provide your own Find*.cmake files, you can. CMake is flexible like that. I haven't used imake so I don't know how it compares to that. Not true. CMake has been developed by Kitware for use in other projects, it got adopted by KDE only later. It has not been developed specifically for KDE. And several non-KDE projects are also switching to it. CMake is not KDE-specific. And no, it's not proprietary in the sense of "proprietary software" either, but I think you know that already. ;-) Kevin Kofler

On Wed, 2008-12-03 at 11:24 +0100, Till Maas wrote: The color gimmicks help you better than the lines displaying what the tools underneath are doing? Pardon, but this logic escapes me. As a developer, maintainer and/or packager you normally want to see what the tools are doing, e.g. if the compiler has received the correct flags, is using the correct libraries etc. Ralf

Till Maas wrote: Because colors only work / are used when the output goes to an interactive terminal. We need a Kate highlighting scheme for cmake-using build.log files. ;-) I do, because I also care when it _will_ finish. :-) Yes, unfortunately. A lot less than the verbose spam does. Kevin Kofler

On Wed, 2008-12-03 at 20:45 -0600, Matthew Woehlke wrote: Very likely because your use-cases are trivial. I am well aware that some people prefer watching progress bars, instead of watching bugs ... the rationale for doing so has always escaped me. Please read what I previously wrote. I don't deny that cmake is easier to get into in trivial use-cases, but cmake very soon loose its "initial" advantages when things become a little less trivial.

Ralf Corsepius wrote: The progress output doesn't hide the errors or warnings, which are the actual bugs in the code. Getting the build flags right is something you do once (in the context of Fedora, when you first submit the package for review) and then you're done with it. Kevin Kofler

At some point, somebody wrote: Come to a conclusion here. Please. jerry -- Store in cool, dry place. Rotate stock.

On Wed December 3 2008, Kevin Kofler wrote: The problem is, that the non verbose build mode hides, whether or not the RPM_OPT_FLAGS are honoured, but it is required to honour them. Maybe cmake needs a way to tell it to only show the compiler invocations, but not the remaining stuff, that is shown with VERBOSE=1 and not useful. Regards, Till

On Thu December 4 2008, Kevin Kofler wrote: This would be the case in an ideal world, but I have already seen a project that modified their autotools stuff to overwrite the CFLAGS unless --enable-maintainermode is passed to %configure (notice the small difference to --enable-maintainer-mode). Therefore I expect everything strange to happen at upstream. And this will probably also happen with cmake, once it is adapted by more projects. With the complete commandline, it is pretty easy to check every now and then, whether the RPM_OPT_FLAGS are honoured. But with cmake, there seems to be more lines in between the gcc, than e.g. with autotools, where they often align pretty nice in a build.log. Also does %cmake also make sure that -O3 / -s is not passed to gcc? Also it seems imposible to see, whether cmake uses "install -s" to install binaries or not. Can %make maybe modified in a way, that it is possible to use something like "rpmbuild --without cmake_verbose" or add something to ones .rpmmacros file to enable/disable this for local/mock rebuilds? Then you would have the flexibility to get only the color/percentage output for your local/interactive builds. Maybe koji can also (be patched to) pass this to e.g. scratch builds, so you can have it there, too. Regards, Till

Hi. On Wed, 03 Dec 2008 18:24:02 +0100, Kevin Kofler wrote: Who cares? If the build succeeded noone will read it, anyway, and log files compress quite well. If the build failed, however, I'd like as much information as possible telling me what exactly was going on when it failed. That includes all options to all commands being run, otherwise you just go around guessing.

Kevin Kofler <kevin.kofler(a)chello.at&gt; writes: At least, 'm4' *has* quoting rules, while it's always an adventure with 'cmake' to write some non trivial things. autotool's language is consistent across its tasks ('make all', 'make install', 'make check', 'make dist'), while 'cmake' uses different tools with different syntax/quoting rules and mechanisms for them. There is so much black magic in 'cmake' that it works for trivial tasks but it is a nightmare to handle complex things with it. Enrico

Matthew Woehlke wrote: POSIX shell certainly. gcc and GNU make definitely not. Being able to build when gcc and GNU make is not present is one of the reasons that the autotools were created. GNU m4 should only be required when the developer is modifying configure.ac, not when the user is building. GNU sed, awk, and bison I'm a little fuzzy in my memory but I don't believe the GNU versions are required. Better to ask an autotools guru about that, though. -Toshio

On Thu, Dec 04, 2008 at 02:40:05PM -0600, Matthew Woehlke wrote: sh, sed and awk are POSIX, and indeed Windows is not POSIX, but most other platforms are, not only UNIX (and GNU is not UNIX). Cmake is not covered by any standard (that I know about). -- Pat

On Thu, Dec 04, 2008 at 04:03:22PM -0600, Matthew Woehlke wrote: Not at all. But although cmake may not be installed on a POSIX system all that is required by ./configure should. I don't mean that cmake is more nor less portable. But vendor cmake may not be more portable than POSIX tools. You mean a specific cmake. But a vendor cmake may be different, with its own set of idiosyncrasies. Looks like you are not compared the same set of tools. GNU POSIX utilities don't have specific idiosyncrasies. I won't comment on that there are too many things that are not clearly defined, and, honestly I don't caare. I don't favor cmake or the autotools. My point is that you are comparing different things. On one hand you have an upstream cmake rebuild on different platforms. On the other thre are different vendor POSIX utilities that may be rebuilt or in binary form that may not share the same source (and you may not even have the source). A fair comparison would be a comparison between, say, GNU POSIX utilities and standard cmake. -- Pat

On Thu, Dec 04, 2008 at 06:09:57PM -0600, Matthew Woehlke wrote: Why so? There could be a solaris cmake, an IRIX cmake, an HP-UX cmake... There could be. Why are there vendor sh, sed and awk? All the GNU POSIX utilities are portable and have been ported on many platforms. I don't know exactly where to check, but I guess that there were even VMS versions of GNU sed, awk and so on, and also apollo versions and so on. -- Pat

I like waf: http://code.google.com/p/waf/ So far been using it in a few (small, but nontrivial) projects and I'm relatively happy with it. The main disadvantage is that because configure runs so quickly, and parallel make actually works, you have less time to switch and check your email while waiting for a project to build.

Karel Zak wrote: That's kinda the point... Tools which are really not intended to be used the way the autotools do. Just look at all the glitches and incompatibilities the extremely complex configure scripts uncover in various implementations (just try to read a configure script and watch how often terms like "bug in ...", "work around" etc. are used in comments - and that's where there _are_ comments). The autotools are abusing shell scripts for things which should be done by real programs (and that's also why they are so slow). CMake doesn't duplicate anything, it just uses C++ rather than shell as its language. The right tool for the job. :-) The autotools are the ones which duplicate functionality by copying the same scripts and script snippets over and over to every single program. There you say it: "UNIX idea" - i.e. non-portable. Not all the world is POSIX (even if we can all wish it was). Kevin Kofler

On Wed, 03 Dec 2008 10:22:00 +0100 Kevin Kofler wrote: OK, I see a lot of vitriol on this thread but its an important topic so I'd like to offer a (hopefully) positive persepective and then ask about the learning part. I want a build system that has the following features: required: + build for multiple OSes (Linux, some *nix, and an occasional windows build -- where mingw may be sufficient) + multiple-language compilation and cross-language linking (C/C++, Fortran, MatLAB/Octave MEX, various scripting languages, etc.) + creation of *both* static and shared libs for C/C++, Fortran, etc. + good documentation and examples -- where "good" means the docs explain what are good strategies/approaches to use for non- trivial projects and *why* desired: + allows either "in-tree" or "out-of-tree" builds + parallel and/or distributed builds that actually work So far, my build system experiences have included: + Plenty of "homegrown" makefiles (both of my own shameful making and from others) -- have learned the hard lesson that it is exceedingly difficult to try to re-implement the flexibility of, for instance, the Gnu autotools + Gnu autotools -- have used them on-and-off for years and have become somewhat comfortable with them -- have run into many problems (mostly of my own making) but, over time, things keep improving and I keep finding (or learning from others) ways to better use the tools provided + Boost Build (aka bjam) -- this is a Jam implementation that was created by the Boost folks and, in my opinion, it has a number of serions problems since: - the jam language is poorly documented and not easy to grasp -- learning a yet-another new language is just more lost time -- and it seems that you have to keep fighting with the Jam files to get anything accomplished - poor support for non-C++ languages - error messages are simply awful - documentation does a lousy job of explaining how you *should* use it for non-trivial projects + CMake -- have tried it a bit and have run into problems (e.g., multi-job builds failing with frustraing race conditions) with the setups created by others -- but it may be that its not the tool per-se just the use of it + have only window-shopped other build systems : Scons, waf, etc. So, with respect to CMake, I'm mostly sitting on the fence. I've had a few less-than-positive experiences with it (have you ever tried to build VTK from source?) but am not completely turned off by it. There is a wonderful tutorial for the autotools: http://www.lrde.epita.fr/~adl/autotools.html but I'm unaware of a similarly helpful (that is, a "this is how you *ought* to use the tool and here are the main reasons *why*") sort of tutorial for CMake. So, what have you folks done to learn about best practices for CMake? And does CMake have good support for all the needs (esp. the multi- and cross-language handling) that I listed? Ed -- Edward H. Hill III, PhD | ed(a)eh3.com | http://eh3.com/

On Wed, 03 Dec 2008 18:33:43 +0100 Kevin Kofler wrote: Hi Kevin, Sure, I appreciate the point about poor use of the tools. But getting back to the meatier issues -- can someone please point me towards: + directions (and examples!) for using CMake for multi-language compiles and cross-langage linking (esp. C/C++ and Fortran) + creating shared libs for the above + manuals (and, if possible, "shining" examples) that describe best practices for non-trivial projects Ed -- Edward H. Hill III, PhD | ed(a)eh3.com | http://eh3.com/

On Mon, Dec 01, 2008 at 10:28:53PM -0500, Jens Petersen wrote: This is stupid advice. Autotools is by far the easiest way to build successfully on all platforms, and to cross-compile code. I invite you to try cross-compiling (for example) gtk2 versus boost, and you will see that writing your own build system, or using a lesser build system that doesn't have all the experience behind it of autotools (or cmake), is an idiotic idea. Rich.

On Sat, Oct 11, 2008 at 10:26 AM, Braden McDaniel <braden(a)endoframe.com&gt; wrote: You would need to patch aclocal.m4 if you need to pull in another external macro. I said that you should patch configure.ac so that you can actually send a patch upstream, like a good consumer would do. Patching a generated file is just a local fix. Would you patch a file generated by bison or would you patch the .y file? One of those is "the right way" and one is not. -- Dan

Till Maas <opensource <at> till.name> writes: But unless you manage to find the exact same versions of the autotools upstream used (which are in general not packaged for Fedora at all), the patch will be huge and contain lots of bogus changes due to the autotools version change. For example, autoconf often adds support for some exotic target or a workaround for some obscure shell's bug from one minor version to the next and that support code or workaround gets copied up to dozens of times into the generated configure script. Also things like copyright dates and revision numbers appear at many places. So a diff for the generated files can be huge even with _no_ change to the sources, and the actual change will be hidden in the mess. Patches of that kind also have to be regenerated at every single new upstream version. In most cases, patching generated files is a bad idea. Kevin Kofler

Till Maas <opensource <at> till.name> writes: Maybe in an ideal world, but here in the real world, not all patches get upstreamed immediately in the next release, and unless this is a large organized project like GCC which enforces very precise autotools versions, the next release will often have used different autotools versions (either because a different developer (often using a different distribution) generated the autotools files or because the maintainer upgraded his autotools, which happens often if they're using e.g. Debian unstable (also if they use Fedora, but in that case, you have at least some hope of hitting the same autotools versions they used)) and so a patch containing lots of bogus changes (i.e. differences completely unrelated to your actual modifications) will almost certainly fail to apply. And this is a really complex solution with lots of manual work for the maintainer to do at each upstream release (your proposed Makefile.common snippets only automate small parts of it, which are just basic diff and patch invocations anyway), you didn't even list all of them (for example, the source tarball has to be extracted to rediff a patch). So I don't get at all how you can think that this compares in simplicitly with: BuildRequires: autoconf automake libtool [and in the %prep section] autoreconf Kevin Kofler

On Sat, 2008-10-11 at 10:44 -0700, Dan Nicholson wrote: No, you don't. You only need to regenerate configure and generate a patch for *it*. The normal process of building a package (i.e., "configure; make") doesn't use aclocal.m4. It's only used to regenerate configure. Yes, but the kind of patches that should be sent upstream are not the ones resulting in 300 busted packages from a libtool upgrade. We're talking about patches applied by a specfile build. -- Braden McDaniel e-mail: <braden(a)endoframe.com&gt; <http://endoframe.com> Jabber: <braden(a)jabber.org&gt;

On Mon, 2008-10-13 at 01:26 -0400, D. Hugh Redelmeier wrote: I couldn't. I hope Karsten Hopp will (the "300" figure comes from him); he's said he's preparing a wiki page with this information. (See earlier in this thread.) I don't know. (And FYI, Fedora never shipped 2.1; I think it wasn't released. I think the 2.2 series succeeds the 1.5 one.) That possibility has been floated; and things might even be leaning that way. See bug 459387. I don't have an objection to that approach as long as "libtoolize" (and similar) refers to the latest version of the tool--just as "autoconf" or "automake" refer to the latest versions of those tools. And as long as that's the case, specfiles for libtool2-incompatible packages that run autoreconf or libtoolize will need to make at least minor changes to request the old version. -- Braden McDaniel e-mail: <braden(a)endoframe.com&gt; <http://endoframe.com> Jabber: <braden(a)jabber.org&gt;

Karsten Hopp schrieb: Braden reminded me to post an update on this ;-) My last rebuild showed only ~100 failures, I'm not sure what I've done differently this time. I suspect that the removal of libtool-ltdl and all related packages from my full-install might have caused this and I'm in the process of rebuilding those with libtool-2. I've uploaded the current logs to http://karsten.fedorapeople.org/ After a quick glance at them I think that there are quite a few easy fixes, but I still have to find out what causes p.e. the cracklib failure. Karsten

On Wed, 2008-10-15 at 06:34 -0700, Dan Nicholson wrote: Or better, just call autoconf instead of autoreconf. (Or do it right and patch configure.) The problem is that libtoolize is getting run at all. Wow... This one's a mess. I don't think that's the problem. In fact, I'm not convinced the problem with this package has anything to do with libtool2. It's hard to see what's going on amid all the warnings about this code that the compiler is spewing; but if you scroll down to the bottom you'll see it's just missing something that goes after a -L flag; presumably some variable isn't getting set for some reason. Or don't. I don't see any reason to regenerate configure in this package. Only Makefile.in is getting patched. Again, this looks like a case where autoreconf doesn't need to be run at all. I see this patching a couple of Makefile.am's; running automake should be sufficient. Eliding the calls to aclocal and autoconf should avoid the problem. It's not clear to me why this spec file is running libtoolize and aclocal at all. I see no reason at all for this to be running autoreconf. (A comment claims it gets rid of an rpath; I'd be a little surprised if this were still true.) Actually, the problem is that it patches both configure.ac and configure. Presumably the timestamps don't line up right as a result and "make" triggers regenerating stuff. Either the patch to configure.ac should be culled or the timestamps need massaging. (There's also a patch to soup.m4 that just looks goofy.) I see no reason to call autoreconf here. Yikes. There's a bunch of magic happening here (of dubious value IMO; but clearly the maintainer doesn't share that view). I'm really not sure what to say here. Yeah, more unusual stuff that's just very breakage-prone. Hard to say if there's a better way without some deep knowledge of this package. Pulling in new libtool here is really unnecessary. The package could simply run autoconf instead of autoreconf. -- Braden McDaniel e-mail: <braden(a)endoframe.com&gt; <http://endoframe.com> Jabber: <braden(a)jabber.org&gt;

On Fri, 2008-10-17 at 06:20 -0700, Toshio Kuratomi wrote: "Only patch configure" is not bad advice. *Including* a patch to configure.ac--in the source RPM and/or in revision control--is sufficient to satisfy any requirement for an upstream-worthy patch. *Applying* a patch to configure.ac when you're also applying a patch to configure can only do harm. It defeats the purpose of patching configure. -- Braden McDaniel e-mail: <braden(a)endoframe.com&gt; <http://endoframe.com> Jabber: <braden(a)jabber.org&gt;

On Thu, Oct 16, 2008 at 11:58 PM, Braden McDaniel <braden(a)endoframe.com&gt; wrote: Again, I'm talking about real fixes to send upstream. There is a very simple, correct way to fix this. If the packager wants to work around it in one way or another, that's an option, but I'm interested in getting things fixed correctly so they stop being broken now and later. Clearly, we're looking at this from two totally different perspectives. -- Dan

On Wed, 2008-10-15 at 12:35 +0200, Karsten Hopp wrote: I don't know what's going on with the libXp and xorg-x11-drv-* failures, we're not doing anything tricky. Someone have a clue? - ajax

2008/10/17 Adam Jackson <ajax(a)redhat.com&gt;: The problem appears to be `autoreconf' vs. `autoreconf -i'. The process goes like this with bare autoreconf: 1) aclocal runs and updates aclocal.m4 with the new AC_PROG_LIBTOOL definition it finds 2) libtoolize is skipped because -i/--install not given, leaving you with an old ltmain.sh 3) fail You can see the process if you add the -v switch to autoreconf. Here's some background on why this happens: http://lists.gnu.org/archive/html/libtool/2008-07/msg00024.html -- Dan

Thomas Moschny schrieb: You're right, libtool isn't involved in that failure. I'll remove monotone from my list. Karsten

Matthias Clasen schrieb: Matthias Clasen schrieb: I'm going to build libtool-2.2.6a soon. As this will bump the soname of libltdl, the following packages depending on that will need to be rebuilt: autodir thias ettercap limb freeradius jdennis gambas2 spot gift rdieter google-gadgets salimma graphviz jima guile mlichvar gyachi sundaram heartbeat kevin ImageMagick nmurray libcanberra lennart libextractor ensc libgphoto2 jnovy libp11 mra mapnik rezso mysql-connector-odbc tgl openct tmraz openhpi sharkcz openldap jsafrane opensc tmraz picviz theinric pinball limb player timn plplot orion pulseaudio lennart rcssbase hedayat sox jmoskovc A copy of this mail goes to the maintainers of these packages. Karsten

Matthias Clasen (mclasen(a)redhat.com) said: That's what I get for not reading closely. Go for it! Bill