bug-gnulib
[Top][All Lists]
Advanced

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

Re: Files from gnulib


From: Jim Meyering
Subject: Re: Files from gnulib
Date: Wed, 26 Jan 2011 14:23:51 +0100

Eli Zaretskii wrote:
>> From: Jim Meyering <address@hidden>
>> >> 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

There would be a rule (always run at least by "make dist") that would
update config.bat.  You could conceivably just run that rule, which
would surely be very quick.  You would not have to run the full "make dist".

However, you might not have to do even that.
You're presuming that people will be adding new files with conflicting
name, but without updating the renaming rules required for DOS.
That's where the automation comes in.
If some rename-shim is required for DOS, then any build target (even "all")
can require it, if it is deemed important enough.  Then, if someone
adds a conflicting file and does not also update the list of rename
pairs, a regular "make" could fail with a diagnostic telling them
what's required.

That would make it the responsibility of each person adding a new
conflicting file to tend to this small infrequent task, not you.

> 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).



reply via email to

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