bug-gnulib
[Top][All Lists]
Advanced

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

Re: Files from gnulib


From: Eli Zaretskii
Subject: Re: Files from gnulib
Date: Wed, 26 Jan 2011 08:09:57 -0500

> From: Jim Meyering <address@hidden>
> Cc: Paul Eggert <address@hidden>,  address@hidden,  address@hidden,  
> address@hidden,  address@hidden
> Date: Wed, 26 Jan 2011 12:13:28 +0100
> 
> >> It is easy to run 'find' as part of the process that makes a
> >> distribution, and to put its output into config.bat or the
> >> equivalent, so there is no need to run 'find' under MS-DOS.
> >
> > More complications.  This means, for example, that to test an
> > arbitrary revision of the development tree, I will need to run
> > make-dist on Unix, create a tarball, copy it to a DOS machine, then
> > build, find problems, go back to the Unix machine, etc.
> 
> Nah.  You wouldn't have to test at all,
> because it could be automated.  See below.

We are miscommunicating.  Paul suggested that config.bat, the script
used instead of the Posix `configure' when building the MS-DOS port,
will have the list of files/directories to rename/edit hardcoded into
it by make-dist.  Which means that to update config.bat, I will need
to run make-dist on a Unix host, then copy the results to the machine
where I build the DOS port, and only then build it.  Just testing
doesn't solve the issue, because if testing detects a problem, the way
to correct it is very complicated (compared to what I do today -- just
edit and try again).

> >> I don't think it'd take much work to do the above.  I can write
> >> scripts to do the check and to do the find, since they can all be done
> >> on a standard GNU platform.  What else is needed?
> >
> > Maintenance.
> 
> [assuming something like doslfn is too buggy -- have you tried it? ]
> 
> We could write an 8.3 conflict-checking Makefile rule and add
> it as a dependent of "check".  Then any new file that conflicts
> would be detected immediately, and whoever added it would
> deal with the failed "make check" by renaming their file or
> by adding a DOS-renaming rule.

"make check" is jut the part that detects problems.  They also need to
be fixed, and that's where most of the maintenance effort goes.  And
what about the need to remember to say "make check"?  Emacs does not
yet have a test suite that can be run as a single large test in batch
mode, so "make check" is not a routine part of building it.

> >> How is that checking done, and what errors doesn't it catch?
> >
> > It's done by the ARI script.
> 
> I didn't find any script in GDB named ARI, but do see
> many references to ARI in ChangeLogs.

I think you will find it on the GDB Web site.  If not, ask on the
gdb-patches mailing list.  I once asked for it and the core
maintainers sent it to me.

> > All I know about the errors is that some files still clash.
> 
> All that means is that there's room for improvement.
> No need to reject that solution because it's not yet perfect.

Either you underestimate the complexity of the task, or you somehow
believe that any complexity can be dealt with reliably.  In both
cases, I really have no practical way of convincing you (and Paul),
because this is no longer about facts, it's about experience and gray
hair.  After so many years of bad experience, I concluded that this
kind of solution will never work reliably, unless someone works full
time on maintaining it.  You are welcome to learn the same lesson the
hard way, but I've learned mine.



reply via email to

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