chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] relevance of autoconf - automake wiki entry?


From: Brandon J. Van Every
Subject: Re: [Chicken-hackers] relevance of autoconf - automake wiki entry?
Date: Mon, 20 Nov 2006 14:06:34 -0800
User-agent: Thunderbird 1.5.0.8 (Windows/20061025)

felix winkelmann wrote:
On 11/20/06, Brandon J. Van Every <address@hidden> wrote:



I'm happy to provide CMake instructions on the wiki if that is deemed
useful.  It's not clear to me who the target audience is for this
"autoconf - automake" page anyways.  I'm not well versed in how people
have typically built things on top of Chicken.  Eggs have some build
capabilities, but not everything is an egg.

I think this is a very good idea: if you could provide CMake-specific
instructions on the wiki, you would both help users and provide an
alternative (once you link to the Manual from your page).

It seems the target audience is "people who write stuff that uses Chicken, but that are not eggs" ? Eggs seem to be built by Chicken eggname.setup scripts; do any actually use autoconf? I looked at a few, and they didn't, but I don't have time to look at every egg.

If that's the target audience, why are we giving them a crash course in autoconf / automake? This stuff is all covered in the GNU documentation, much more thoroughly than you're capable of doing here. I'm seeing very little that's Chicken-specific on the autoconf - automake wiki page. A canonical clear example, that actually works and is actively maintained, would be a good idea. But I don't personally see the wiki page itself as helpful, as it stands. I'm saying less talk, more demo.

Packaging up macros that people typically use in a build package is a worthwhile project. For instance, I could generalize the Chicken finder stuff into a FindChicken macro, and possibly even get it included in a later version of CMake. It's even possible to make language-specific bindings for CMake, somehow, but I haven't felt like taking that on. People similarly distribute m4 macros for Autoconf. Not that I'm suggesting you do it, please spend your energy on something else! but I'm saying that's what people do when they want to improve the support of a build tool. I don't think rambling on about the basics of how to use the build tool is helpful; they should RTFM. And if that's too hard, they should UAFT (Use Another ***ing Tool).

Also it is not entirely clear to me whether developers "should naturally" want to use an Autoconf / CMake type tool, or whether they would want to use Chicken scripting. I'm not sure how much the Chicken eggs stuff can be used for non-eggs. Seems more logical to promote the use of Chicken itself, to whatever degree it can actually be used. Of course, there are pure Scheme and mixed Scheme / C / C++ projects to consider.



I understand your effort to make CMake more prominent, and I dislike
autotools at least as much as you do. But for many UNIX users it is still the
more portable (yes, a very very fragile form of "portable") or easier
to use (This will hopefully change.in the future, but unfortunately we are
not there yet). But this doesn't mean that the wiki shouldn't contain
instructions on how to integrate code with those tools. Users should get
any support that can be provided.

I don't object to the autoconf instructions being there, if someone is actively developing that page and trying to make it a good reference. Currently it isn't. It's very incomplete. That's why I asked if it's a living or dead project.

I do object to the autoconf instructions taking front and center stage any time someone opens the Chicken User's Guide for the 1st time. It's an accident of mutual wiki linking; I don't think it's appropriate. The only reason the mutual link exists is because an ongoing example is shared by the autoconf page.

Having more sleep now, I looked at the autoconf wiki page again. It has 3 links: one to the actual example, one to the page the example is on, and one to the top level of the User's Manual itself. This is rather redundant, so I have taken the liberty of removing the User's Manual link. I also added a link from the compiler examples page to the autoconf - automake page. This solves my issue, and I don't think it impacts anyone else's issues.


Cheers,
Brandon Van Every





reply via email to

[Prev in Thread] Current Thread [Next in Thread]