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

Re: [9fans] Silly porting fun

[Lucio De Re]

On Fri, Jul 14, 2000 at 10:58:58AM +0000, forsyth@caldo.demon.co.uk wrote:
> 
> i should be making a portable version of mk available shortly from a Vita Nuova site.
> it's the version used to build Inferno on Unix and Windows.

Does that mean you haven't ported "mash" yet?  :-)  :-)  :-)

I only browsed the mash documentation, but it seemed very intriguing.

++L

Re: [9fans] Silly porting fun

[dhog]

Oh no, the echo is back.

Re: [9fans] Silly porting fun

[Russ Cox]

	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.

Actually I think that part of the script is just broken.
It detected GSSAPI on Plan 9 too.  That was when
I gave up and edited config.h.in into config.h by
hand.  I have a couple scripts called def and undef,
and I just sit in acme piping lines through one or
the other.  It doesn't take very long at all.

Russ

Re: [9fans] Silly porting fun

[bobf]

> >>What I'd like to see...  mk for Unix :)  Anyone here who has attempted to port
> >>it over (along with rc of course)?
>
> i should be making a portable version of mk available shortly from a Vita Nuova site.
> it's the version used to build Inferno on Unix and Windows.

i should point out that the version of mk released with inferno
accepts recipes in either rc or sh syntax, so it is not necessary
to port rc.

on windows, we use a stripped-down version of rc that sean quinlan
hacked.  it's not fully functional, but communicates with mk well
enough to do builds.

Re: [9fans] Silly porting fun

[forsyth]

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

i should be making a portable version of mk available shortly from a Vita Nuova site.
it's the version used to build Inferno on Unix and Windows.

Re: [9fans] Silly porting fun

[Douglas A. Gwyn]

rob pike wrote:
> Why should I type
>         ./configure
>         make
> ?

Because in the real world it is more likely
	./configure
	sam makefile # fix the *!#$^&@ makefile
	make

Re: [9fans] Silly porting fun

[pip]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

> Why should I type 
>	./configure
>	make
> ?
> Surely make can run configure for me.

I'm not arguing in defense of, or against any particular kindergarten
of thought, but:

Quite obviously at that point you do not even have a Makefile,
so that would require a bootstrapping Makefile that gets replaced
by the real Makefile that configure generates. In general you might
want to call configure with certain parameters. 

I generally never do a ./configure right away, but do a './configure --help'  
or peruse some config* files to see what options I can pass to configure,
 'cos I generally end up needing an option to install into a non-standard
bin directory, for various reasons like I'm not doing the install as
root or I need to override the default parameters 'cos I'm compiling
a package for a different arch with a cross-compiler.

but that's just me and I'm a weirdo.
-
pip


[-- Attachment #2: Type: message/rfc822, Size: 1395 bytes --]

From: "rob pike" <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Silly porting fun
Date: Thu, 13 Jul 2000 19:58:38 -0400
Message-ID: <200007132358.TAA15417@cse.psu.edu>

Why should I type
	./configure
	make
?
Surely make can run configure for me.

-rob

Re: [9fans] Silly porting fun

[rob pike]

Why should I type
	./configure
	make
?
Surely make can run configure for me.

-rob

Re: [9fans] Silly porting fun

[Russ Cox]

If you want auto-configuration, autoconf is
indeed the cream of that particular crop,
especially compared to some other
systems I've seen.  You're correct that rolling
your own auto-configuration program is not
a good idea.

As long as package authors stick to even
more basic principles about writing portable
_code_, auto-configuration is not necessary.
Then there are no build parameters to tweak.
I cite as examples drawterm, newsqueak,
and sam.  I'm sure there are less parochial ones.

(In drawterm, it does not cease to amaze me
that the only difference between the code used
under FreeBSD and the code used under Irix
is five lines of assembly for test-and-set.  And
there are no #ifdefs.)

Russ

Re: [9fans] Silly porting fun

[Douglas A. Gwyn]

Latchesar Ionkov wrote:
> Anyway, if you add
>         #include "u.h"
>         #include "libc.h"
> in your minimal program it will compile and link just fine.

I think you miss the point.  The "configure" script tries to
compile a *standard-conforming* test program in an attempt to
detect a usable C compiler on the system.  The test program
must *not* be platform-specific.

The main problem of course is that the configure script only
probes for things that have been previously discovered about
various porting targets.  It apparently doesn't know how to
find the Plan9 APE environment, i.e. "pcc" is not one of the
names it tries to find a C compiler.  My guess is that adding
"pcc" to the list *before* "cc" will get past that particular
snag.  There may be other snags; the other day I had a GNUish
package fail to autoconfigure due to there being a "gcc" in
my path (effectively a union /bin) that was not a native
compiler (it was a cross-compiler for an embedded processor).

Re: [9fans] Silly porting fun

[Randolph Fritz]

On Wed, Jul 12, 2000 at 08:31:36PM -0400, Russ Cox wrote:
> 	The compiler, reasonably enough, decides that this routine never does
> 	anything and is never called, and optimizes it out of existence!  The
> 	linker then cannot find main(), and fails.  Is there an option switch
> 
> That's not what's happening.
> The linker cannot find _main, which
> calls main, because there have been
> no #pragma lines that tell it where
> to find libc.a.
> 

I stand corrected.

> 
> If you really want configure to run,
> find the line that says ``AIX loses...''
> and change the next line, which is
> 	echo > foo.c
> to
> 	echo '#include <stdio.h>' > foo.c
> Then things usually ``work''.
> 

Thanks.

>
> A well written build process is usually
> easy to convert to mk, often by guessing.
> I ported cvs yesterday, creating mkfiles
> by processing the output of ls *.c, and
> it worked the first time.
> 

This, of course is also an excellent point.  My hacking was intended
as a first cut, not a finished port.

-- 
Randolph Fritz
Eugene, Oregon, USA

Re: [9fans] Silly porting fun

[Randolph Fritz]

On Wed, Jul 12, 2000 at 04:46:35PM -0700, Christopher Nielsen wrote:
> 
> The whole GNU configure script idea always seemed like a giant kluge to
> me; an artifact of having to live in a world of various flavours of UNIX.
> 

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.  (Just don't ask
me to write the !@#% things! :)

"I am in a maze of twisty Unix versions, all different."

> Space monkeys ate my brain: No such file or directory

Chuckle.
-- 
Randolph Fritz
Eugene, Oregon, USA

Re: [9fans] Silly porting fun

[arisawa]

Hello,

>The GNU configure script provided with Python wouldn't work.
Practically speeking, it is much easier to port programs that are  
already configured for some platforms to plan9.
Python for Plan9 was ported using codes for FreeBSD(or NEXTSTEP --
I forgot).

Configure does work on popular platforms and we can exactly  
interpret
the codes to that of Plan9.

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

Re: [9fans] Silly porting fun

[Christopher Nielsen]

On Wed, 12 Jul 2000, Russ Cox wrote:

> 	The whole GNU configure script idea always seemed like a giant
> 	kluge to me; an artifact of having to live in a world of various
> 	flavours of UNIX.
> 
> You make it sound as though it's the only
> thing to do when living in such a world.
> There are ways to get portable code without
> configure.

Hrm... I guess it does sound that way. It certainly wasn't meant to sound
like that. :-)

There are, of course, many things a programmer can do to make code more
portable.

-- 
Christopher Nielsen
(enkhyl|cnielsen)@pobox.com
Enkhyl on IRC
Space monkeys ate my brain: No such file or directory

Re: [9fans] Silly porting fun

[Russ Cox]

	The compiler, reasonably enough, decides that this routine never does
	anything and is never called, and optimizes it out of existence!  The
	linker then cannot find main(), and fails.  Is there an option switch

That's not what's happening.
The linker cannot find _main, which
calls main, because there have been
no #pragma lines that tell it where
to find libc.a.

In Plan 9, the name you type is the
name that gets used.  No underscores
are added or removed.

I find that the only thing configure 
doesn't do right for APE is try to
compile empty files.

If you really want configure to run,
find the line that says ``AIX loses...''
and change the next line, which is
	echo > foo.c
to
	echo '#include <stdio.h>' > foo.c
Then things usually ``work''.

A well written build process is usually
easy to convert to mk, often by guessing.
I ported cvs yesterday, creating mkfiles
by processing the output of ls *.c, and
it worked the first time.

Russ

Re: [9fans] Silly porting fun

[Russ Cox]

	The whole GNU configure script idea always seemed like a giant kluge to
	me; an artifact of having to live in a world of various flavours of UNIX.

You make it sound as though it's the only
thing to do when living in such a world.
There are ways to get portable code without
configure.

Russ

Re: [9fans] Silly porting fun

[Christopher Nielsen]

On Thu, 13 Jul 2000 forsyth@caldo.demon.co.uk wrote:

> >>interested in a solution for it, since many widely-available programs
> >>depend on such scripts.  A GNU "configure" script is a shell script
> 
> there is a more serious problem to many of the configure scripts
> (in my experience).
> 
> having done all that probing, quite a few of them announce that
> they think they know where things are but don't recognise your system anyhow.
> it hasn't been named in a huge case statement.
> they seemed really to be enumerating all the things they'd come across so far.
> that's portability.
> 
> now i just edit the config.h to form config.h.plan9, do ape/make -n,
> build a corresponding mkfile, and am done with it.
> the configure doesn't usually configure properly for building several architectures
> (big AND little endian) simultaneously in one directory.

The whole GNU configure script idea always seemed like a giant kluge to
me; an artifact of having to live in a world of various flavours of UNIX.

-- 
Christopher Nielsen
(enkhyl|cnielsen)@pobox.com
Enkhyl on IRC
Space monkeys ate my brain: No such file or directory

Re: [9fans] Silly porting fun

[forsyth]

>>interested in a solution for it, since many widely-available programs
>>depend on such scripts.  A GNU "configure" script is a shell script

there is a more serious problem to many of the configure scripts
(in my experience).

having done all that probing, quite a few of them announce that
they think they know where things are but don't recognise your system anyhow.
it hasn't been named in a huge case statement.
they seemed really to be enumerating all the things they'd come across so far.
that's portability.

now i just edit the config.h to form config.h.plan9, do ape/make -n,
build a corresponding mkfile, and am done with it.
the configure doesn't usually configure properly for building several architectures
(big AND little endian) simultaneously in one directory.

Re: [9fans] Silly porting fun

[Latchesar Ionkov]

On Wed, Jul 12, 2000 at 02:16:20PM -0700, Randolph Fritz said:
> 
> The typical minimal main program from a GNU configure script is:
> 
>   main() { return(0); }
> 
> The compiler, reasonably enough, decides that this routine never does
> anything and is never called, and optimizes it out of existence!  The
> linker then cannot find main(), and fails.  Is there an option switch
> (preferably) or #pragma I can give to alter this behavior?  Failing
> that, would adding "USED(main);" to the program do the trick?

Compiler cannot decide whether a (global) function is used or not -- that's 
linker job.

Anyway, if you add

        #include "u.h"
	#include "libc.h"
		
in your minimal program it will compile and link just fine.
		
Regards,

	Lucho
			

[9fans] Silly porting fun

[Randolph Fritz]

So...having cut and ground my teeth on some basics of Plan 9, and
being temporarily unable to download Kenji Arisawa's port of Python, I
decided to try building Python in the APE.  The GNU configure script
provided with Python wouldn't work.  (I am now downloading Arisawa's
port.)

Upon study, I found the source of the difficulty, and I would be
interested in a solution for it, since many widely-available programs
depend on such scripts.  A GNU "configure" script is a shell script
which tests the local system for various features.  It does this, in
part, by compiling many small test programs.  Often the point of the
test programs is a check for the presence of an include file or
symbol, and the main program is trivial.  And therein lies the
problem.

The typical minimal main program from a GNU configure script is:

  main() { return(0); }

The compiler, reasonably enough, decides that this routine never does
anything and is never called, and optimizes it out of existence!  The
linker then cannot find main(), and fails.  Is there an option switch
(preferably) or #pragma I can give to alter this behavior?  Failing
that, would adding "USED(main);" to the program do the trick?

-- 
Randolph Fritz
Eugene, Oregon, USA