Re: [patch] Get coreutils 6.1 to build on a ANSI 89 compiler

[mwoehlke]

Bob Proulx wrote:
> mwoehlke wrote:
> > I have built coreutils (actually, a nice GNU suite plus a few others 
> > like VIM7) on over a half dozen platforms, including Solaris 2.7, Irix, 
> > HPUX 11.x, AIX... and of course Linux. These are "old" systems, but they 
> > are still used in production (we keep them because our customers still 
> > use them).
>
> Hmm...  Are your customers also using the latest code on those
> machines?  I would guess those are effectively stable appliances which
> is why they are frozen there.  Running with the latest code is not
> going to match their environment.  And if the customers were using the
> latest software then I would pose the same question to them concerning
> modifying it with upgrades.

Some have "issues" upgrading, yes, but many of them do upgrade. Some of 
them are also government, or otherwise have strange rules or problems 
regarding ability to upgrade (either hardware, software, or both).

(Since I'm essentially hijacking your request for comments, I'll take my 
other comments to Paul's much more succinct reply, and reply only to 
direct questions or things relevant to your original question.)

> > Now, to answer the original question, I *think* most of those have a C99 
> > compiler available, but without checking all ten OS/hardware 
> > combinations (not counting Cygwin, where I use the officially maintained 
> > toolchain), I can't say that with certainty.
>
> How would you propose that we determine this information?  I can't
> think of a better way than to make a coreutils release that relies
> upon the desired c99 features, with an easy way to patch back to c89.
> If there are no bug reports of any type then we can assume that no one
> is using new coreutils on museum pieces.  If there are lots of real
> and valid bug reports then we have our information.

Right. Most likely I will build the next "stable" coreutils across the 
board, at which point I expect I will probably file a few bug reports 
(or one, with many parts) detailing how to detect and enable c99 for 
various platforms (particularly on systems where the answer is an 
esoteric compiler option rather than 'c99').

> I think this is okay because by definition if you are compiling source
> code you have assumed the role of a developer, or at least a code
> porter, and developers and code porters are assumed to have a higher
> skill level than a non-developer.  This issue is well within reason to
> expect them to be able to deal with effectively.  With the README
> saying explicitly what needs to be done and the patch provided it is
> very easy.  Perhaps too easy.

Right. We are in violent agreement. :-)

> > I'm not against making C99 a *soft* requirement (part of building that 
> > toolchain I mentioned was dealing with non-C99 compilers - not just with 
> > coreutils), especially if configure tries to find a C99 compiler if you 
> > didn't point it at one explicitly (how many OS's does this work with, 
> > btw?), but there are still systems used by real people (and by big 
> > companies!) that certainly don't have C99 by default.
>
> So let's turn this into useful information.  Among the platforms that
> you are using do you have any that are not capable of using a c99
> compiler?

Again, without checking I won't know, but I think you've got the right 
strategy here. As mentioned above, once there is a "stable" release out 
(sounds like it will be relatively soon), I expect to do a round of 
builds, at which point I'll be able to tell you what broke and 
(hopefully) how to fix it.

Checking the two most likely suspects, however; I don't see a 'c99' on 
NSK/OSS, and the help for 'cc' mentions 'c89', which is not a good sign. 
Irix however has a 'c99', and I *think* the rest of my set probably have 
some means of compiling c99.

> I am not sure coreutils would be doing a service to the community to
> add automatic back patching of the code on systems without c99
> available.  Having to do it explicitly today acts as a wakeup-call to
> people that they should be thinking and planning for how to deal with
> the support issue for their ancient platform.

Nope, no disagreements here. :-)

--
Matthew
KATE: Awesome Text Editor