Software Carpentry design submissions posted

Posted 15 Apr 2000 at 22:38 UTC by raph Share This

The initial submissions for the Software Carpentry design competition are now posted. There were 75 entries from 15 countries, including two of mine. Interesting reading!

I read, or at least skimmed, all of the entries in SC Build and SC Config. Overall, I wasn't too impressed with the quality. There were quite a number of Windows-flavored entries requiring a GUI-based config tool. My guess is that these would be adopted by the Linux community some time after hell freezes over.

I also got the distinct impression that a major problem with the contest is factorization of the building problem into modules. The competition is organized along the same the same factorization as make and autoconf, which I am not at all fond of. In fact, I think it's very likely that an entirely different factorization would lead to a simpler, better solution. After all, make and autoconf, while they both have their warts, actually do a pretty good job at what they do. Why, then, are we still unhappy?

A lot of people recognized the importance of namespaces. This is good, as improper management of namespaces is a significant problem with the existing tools.

The project file format seemed to me to be pretty evenly split between Makefile-like, XML, and Python code. You know, it probably doesn't end up mattering all that much, it's pretty much syntax. I dislike putting code in there myself, as it makes it a hell of a lot harder to analyze or visualize the project file, but I'm sure other people will appreciate the added power.

There is supposed to be a discussion on the sc-discussion mailing list, but the archive stops around the end of March. Hopefully this will get fixed soon. In any case, discussion here is always welcome.

Why we're still unhappy..., posted 16 Apr 2000 at 01:58 UTC by zw » (Master)

In my opinion, people don't like make or autoconf because they require you to jump through too many hoops. Yes, both are quite powerful and both do the job (autoconf more so than make). But you have to know far too much, and be far too clever, to use either one effectively. For example, to use autoconf safely you have to know how to write a portable shell script, and that's actually harder than writing portable C. This wouldn't be a problem if autoconf's macro database included all the tests you ever needed, but it doesn't.

I didn't see any of the SC Config entries that addressed the problem of what you do if the test you need isn't a prewritten unit. It's best served by an online repository of units, I think. (Something like this exists for Autoconf, but the architecture doesn't really fit dropping in chunks - you wind up with a monstrous aclocal.m4.)

Bruce Korb's entry takes an interesting approach: have a compatibility library that deals with all your problems for you. I like this idea. GCC and binutils already have something similar, called libiberty, and it works quite well. However, it's rather hard to decouple from GCC.

Unhappiness, posted 16 Apr 2000 at 16:29 UTC by crj » (Journeyer)

Hey, thanks for that autoconf repository link. I had hoped something like that existed, but could never find it.
automake/autoconf are great once you learn how to use them and get everything set up OK.
I think it is getting over that learning part that is hard part.
My problem is that the documentation for these tools is, um, highly distributed.

There are a few tutorials in various levels of completeness.

Learning autoconf and automake
automake and autoconf with c++
learning GNU development tools (this one is excellent!)

Thats the good stuff, but you have to find them.
The info pages, the first place you might check, are weak - at least for automake. Yesterday I was trying to answer find the answer to a basic question: "how do I install my header files for a library". I went to the info page on this subject, "other objects-> headers" and it says :

Header files are specified by the HEADERS family of variables....

All header files must be listed somewhere...

Headers can be installed in includedir, oldincludedir or pkgincludedir

I couldn't help but notice that it did not say:

For example, if want to install the header files foo.h and bar.h in the directory (prefix)/include/foobar, and you specifed your shared library using lib_LTLIBRARIES = , you should put these lines in your

libfoobarincludedir = $(includedir)/foobar
libfoobarinclude_HEADERS = foo.h bar.h

So I am pulling my hair out and instead of spending 5 minutes checking the documentation, I spend 50 minutes looking through a bunch of complicated real world examples to figure out the correct syntax.

Re: Unhapiness, posted 17 Apr 2000 at 10:07 UTC by jamesh » (Master)

The automake manual is written more as a book than as `random access' online help. I am sure that if you read some of the nodes before the one you mentioned, things would have made more sense.

There is a need for more documentation for many tools.

Better late than never, posted 11 Oct 2010 at 16:11 UTC by bkorb » (Journeyer)

Since this contest was run, "gnulib" became the other-than-GCC-and-binutils libiberty. The downside is that when you run configure, it now burns the majority of a project's build time. It is _really_ clever and all, but several minutes of configuring for a several second compile is more than a little over the top.

Well, guess what? My entry from a decade ago is coming to fruition!! gnulib is getting a libposix glue on that will result in exactly what I proposed all those many years ago! It will likely take a few more weeks to get fully polished, but the rudiments are going into gnulib today!

Cheers - Bruce

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page