[Top][All Lists]

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

Re: [Gnucap-devel] git repo proposal

From: Felix Salfelder
Subject: Re: [Gnucap-devel] git repo proposal
Date: Mon, 27 May 2013 12:01:36 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, May 27, 2013 at 03:13:43AM -0400, al davis wrote:
> I am getting ready to go away for a week .
> I tried autoconf-WIP.
> Problem noted:  It left out the ".model" files in apps.  These 
> are the ones that need modelgen to generate the C++ code.

my bad. i'll add it.

> As to what bothers me about autoconf ...  a few bad experiences 
> and no good ones ...

that's more difficult to fix. lets postpone it :)

> but it does a lot of stuff that it shouldn't.  For example .. 
> "checking for gawk" ...  Why?  Gnucap doesn't use gawk.

gnucap doesnt use make or bash either. autotools does.

> I 
> didn't see anything there to indicate that you asked for it, so 
> why did it do it anyway?

grep AWK config.status

> Then it checks for a bunch of C header files, that gnucap 
> doesn't use, and doesn't check for the C++ headers that gnucap 
> does use.

i'll have a look. didn't check most of this. its taken from the previous
gnucap release.

> Also, lots of files in the project root.  What is there before 
> running makes sense and is ok.  I am referring to the 
> generated files, which are included in a tarball.  The most 
> naive of the users that build from source see them first and 
> have no idea what they do.  Can these be moved aside to a 
> subdir?

the ordinary user should never have to touch the tarball (why should
(s)he want to?). but i can check if autotools allows putting files
somewhere else if you insist.

> First bad experience .. I think it was about version 0.12 ... 
> just moved to C++ from C. ...  Manu Rouat sent me autoconf 
> files, and I couldn't make it work on any machine I had access 
> to.  I think he was using Linux, but I only had access to Next, 
> Sun, Dec (VAX and Alpha), SGI, Gould, and Alliant.  My system 
> handled all of them, but the autoconf version didn't, and I had 
> no idea what to do, and since he didn't have those machines he 
> didn't either.

that's bad.

> One problem was dealing with templates.  There's the Borland 
> method, the Cfront method, the Gnu method ... and the code had 
> to change based on which one was used.

what templates? make? c++? it sounds like this is no longer a problem.

> About a year later, I put together a Linux machine, installing 
> it from a pile of floppys.  Two years later I got my own Linux 
> machine.  By this time Slackware was available.
> I understand why you NEED something like autoconf.  What I don't 
> understand is why it has accumulated so much cruft over the 
> years, and it doesn't seem to bother anyone who has the power to 
> do anything about, yet it is often pointed to by the detractors 
> of Free software.

hmm it works on gnu systems. many people don't have acces to non-gnu

but: i really don't NEED autotools. i (and others) need the
functionality. most of it could probably be added to your handwritten
makefiles, other things are more difficult. now that there is a git
repo, anyone is invited to try without autotools:
- dependency tracking (no, i mean automatic)
- VPATH support (the standard way)
- DESTDIR support
- a dist target
- distcheck (!)
- config.h
- many options i don't even know about

> If you looked at the line that led to what is now gnucap, you 
> would see all kinds of stuff.  Go back to the beginning, it's in 
> Fortran.  A little after that it was Ratfor with M4 macros, and 
> critical parts hand coded in Z-80 assembly.  Been there, don't 
> want to go back.  Several times, ACS/gnucap has changed, 
> hopefully making it better and cleaner.  I think the progress is 
> good.
> I think if autoconf would do that too, it could be truly 
> excellent.  I am bewildered at why they don't.

that holds for most software. autotools is just good enough as it seems.
what they need is competitors. all other attempts to write build systems
i know of have failed.


reply via email to

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