Re: [9fans] Silly porting fun

Re: [9fans] Silly porting fun

[forsyth]

>>I sometimes think so too and yet...it works so very very well and
>>there is just so much software that uses it.  I don't think I've ever
>>seen a configure script fail in a released program. 

i have, frequently, on Unix systems, not Plan 9.
it just has to be one version on (and not differing in essentials)
that they haven't seen before.  the manufacturer tweaks an
include file or moves a library and they fall apart.  makes you wonder why they
bother to probe.  (made me wonder, anyway.)
when that happens, and this is the reason the scheme doesn't
work `very well' (except when it has essentially nothing to do),
you will have the penguin's own time working out what those scripts
are doing, and untangling some bizarrely structured makefiles.

>>(Just don't ask me to write the !@#% things! :)

they use a program to generate them based on some sort of description.
it's a similar idea to all those compilers years ago for the sendmail rewrite language:
don't fix the problem, just bulk it up.  i take comfort from the thought that
whoever writes these things might have decided to become surgeons instead of
programmers.

Re: [9fans] Silly porting fun

[Greg Hudson]

> i have, frequently, on Unix systems, not Plan 9.  it just has to be
> one version on (and not differing in essentials) that they haven't
> seen before.  the manufacturer tweaks an include file or moves a
> library and they fall apart.  makes you wonder why they bother to
> probe.  (made me wonder, anyway.)

Plan 9 people have an incredible propensity to focus on the occasional
failure of common Unix models and ignore the successes.  The
principles behind the autoconf model are:

	* You'd like your program to compile, on a wide variety of
	  systems, when the user types "./configure" and "make".  So
	  you don't want to do things at build time which won't
	  compile or link.  The best way to find out whether something
	  will compile or link on a given system is to try it out at
	  configure time.

	* You don't want to require builders to have special tools on
	  their system to build your program.

As long as package authors stick to these principles, autoconf works
quite well, even if it is just a kludgy collection of m4 macros.  It
doesn't matter if a vendor tweaks an include file or moves a library;
either a candidate bit of code will work on that system or it won't.
Unfortunately, not all portability issues can be handled by simply
trying to compile and/or link a finite number of code samples, and not
all package authors understand or care about the above principles, so
you get the occasional problem.  But really, I've dealt (as an
integrator) with a lot of autoconfigured programs on a lot of systems,
and I've never wished that a program didn't use autoconf.

On the other side of the coin, as someone mentioned, you can try to
make your software portable without autoconf.  That trick almost never
works well.  You invariably wind up creating a complicated one-off
system with its own weird conventions for tweaking various build
parameters.  I've played integrator for a lot of programs which take
this approach, and I've always wished that they used autoconf.

> you will have the penguin's own time working out what those scripts
> are doing, and untangling some bizarrely structured makefiles.

"Working out what those scripts are doing" is usually a matter of
looking at config.log.

Bizarrely structured makefiles are not autoconf's fault.  I've written
lots of autoconfigured packages with extremely concise and
understandable Makefiles.  They may be automake's fault, though.

Re: [9fans] Silly porting fun

[peter huang]

"Greg Hudson" <ghudson@mit.edu> wrote in message
news:200007131601.MAA01725@egyptian-gods.mit.edu...
 >
> Plan 9 people have an incredible propensity to focus on the occasional
> failure of common Unix models and ignore the successes.  The
> principles behind the autoconf model are:

I would re-phrase that to all peoples working on machines that autoconf does
not  support.

>
 > On the other side of the coin, as someone mentioned, you can try to
> make your software portable without autoconf.  That trick almost never
> works well.  You invariably wind up creating a complicated one-off
> system with its own weird conventions for tweaking various build
> parameters.  I've played integrator for a lot of programs which take
> this approach, and I've always wished that they used autoconf.

again, for unix derived or like systems where autoconf is supported,
autoconf is a blessing.  However, once you moved off the supported
platforms, that is where the break down occurs.  For examples, it took 2
years before  HPUX11 get supported on autoconf.  Even that is not very good
(32 bits verus 64 bits, gcc versus ansic ....)   Configure script in OpenSSL
does not use autoconf and I would like to see someone put together a
configure.in file that can meet the need.  My point is that autoconf is
great for many general unix apps but fail short to deliver some real hard
one.

I perferred a simplier approach and that is why plan9 appeal to me and mk is
easier to understand (if only I can find a mk on the unix).

-peter

Re: [9fans] Silly porting fun

[Kris Van Hees]

In article <200007130836.EAA20995@cse.psu.edu>, forsyth@caldo.demon.co.uk wrote:
>>>I sometimes think so too and yet...it works so very very well and
>>>there is just so much software that uses it.  I don't think I've ever
>>>seen a configure script fail in a released program. 
>
>i have, frequently, on Unix systems, not Plan 9.

One example is trying to compile CVS (ironically, since it already got ported
to Plan9 without much trouble - and not using configure) on Solaris 7.  At
least on all Solaris 7 machines I tried it detects that GSSAPI is available,
and then during the compilation it complains because the libraries are not
there.  I believe it must be a case of Sun shipping the C include files but
not the library or something.

Anyway, it indicates how fragile configure is, even on one of the very common
Unix flavours.  Another thing I truly *hate* about configure is that its small
components like the infamous config.guess script to create a identifier for the
architecture/platform it runs on cannot be used under non-GPL distribution
terms unless it is bundled with a program that contains a GNU configure script
that was generated with Autoconf.  Quite a ridiculous stand for people that
claim to promote 'free' software, I think.  Anyway, that widely off topic.

What I'd like to see...  mk for Unix :)  Anyone here who has attempted to port
it over (along with rc of course)?

	Kris

Re: [9fans] Silly porting fun

[Douglas A. Gwyn]

Kris Van Hees wrote:
> What I'd like to see...  mk for Unix :)  Anyone here who has
> attempted to port it over (along with rc of course)?

I'm pretty sure "mk" was available from the UNIX System ToolChest,
currently shipped via CD-ROM for a modest price (along with Unity
DBMS, Sam, Spin, Map tools, etc., probably not current versions
although I'm not sure about that).

Re: [9fans] Silly porting fun (RC for Unix)

[Steve Simon]

A rewrite of RC for Unix was done several yars ago

source:	viz.tamu.edu:/pub/rc/rc-1.4.tar.Z
FAQ:	http://www.df.lth.se/~elg/rcfaq.html

I have compiled it under CYGWIN (sourceware.cygnus.com)
and use it under NT at work daily.

-Steve

 but Kris Van Hees wrote:
[snip]
> 
> What I'd like to see...  mk for Unix :)  Anyone here who has attempted to port
> it over (along with rc of course)?
> 
>         Kris

Re: [9fans] Silly porting fun

[Christopher Browne]

Centuries ago, Nostradamus foresaw a time when Kris Van Hees would say:
>In article <200007130836.EAA20995@cse.psu.edu>, forsyth@caldo.demon.co.uk wrote:
>>>>I sometimes think so too and yet...it works so very very well and
>>>>there is just so much software that uses it.  I don't think I've ever
>>>>seen a configure script fail in a released program. 
>>
>>i have, frequently, on Unix systems, not Plan 9.
>
>One example is trying to compile CVS (ironically, since it already got ported
>to Plan9 without much trouble - and not using configure) on Solaris 7.  At
>least on all Solaris 7 machines I tried it detects that GSSAPI is available,
>and then during the compilation it complains because the libraries are not
>there.  I believe it must be a case of Sun shipping the C include files but
>not the library or something.
>
>Anyway, it indicates how fragile configure is, even on one of the very common
>Unix flavours.  Another thing I truly *hate* about configure is that its small
>components like the infamous config.guess script to create a identifier for the
>architecture/platform it runs on cannot be used under non-GPL distribution
>terms unless it is bundled with a program that contains a GNU configure script
>that was generated with Autoconf.  Quite a ridiculous stand for people that
>claim to promote 'free' software, I think.  Anyway, that widely off topic.
>
>What I'd like to see...  mk for Unix :)  Anyone here who has attempted to port
>it over (along with rc of course)?

You might want also to take a look at the Software Carpentry project
for "SC Config" <http://software-carpentry.codesourcery.com/sc_config>

This is a project specifically intended to provide a successor to
autoconf.
-- 
aa454@freenet.carleton.ca - <http://www.hex.net/~cbbrowne/langide.html>
"When we understand knowledge-based systems, it will be as before 
-- except our fingertips will have been singed."  -- Alan Perlis