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 autogen.sh 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 systems. 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. regards felix _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
