Re: Building SVN source failures: VPATH builds; Cygwin

[Hans-Bernhard Bröker]

Am 14.01.2017 um 18:47 schrieb Eli Zaretskii:
> > Cc: address@hidden, address@hidden
> > From: Hans-Bernhard Bröker <address@hidden>
> > Date: Sat, 14 Jan 2017 16:31:51 +0100

> > The reason I started this thread was that the ones in place really
> > didn't.  The rules to generate fresh files weren't even run, because the
> > VPATH rules believed there was no need.  But the rules using them didn't
> > find them.  Worse yet, the gnulib configuration ruls failed _silently_,
> > causing rather weird compiler errors.
>
> That just means the Makefile rules need some tweaking to DTRT.  The
> solution is not necessarily removal of the files from the repository.

In the case at hand for the majority of files concerned, I'm quite 
convinced it was.  Files that are built by 'configure' or 'make' should 
never be distributed, neither in the repository nor in tarballs.

Neither does it make much sense to have in SVN both an 'autogen.sh' 
script and the files it generates (Makefile.in, mainly).

> That you don't see them as exotic doesn't mean everyone else think the
> same, or have them installed everywhere.  In particular, having that
> on Windows is not a trivial thing.  (Yes, I do have them, but many
> people cam up complaining that they couldn't set up these tools
> correctly.)

On Windows, being prepared to use 'configure' or the Makefile it 
generates is every bit as exotic as having autoconf and autoamke.  I.e. 
either you have ready access to all of them, e.g. via MSys or Cygwin, or 
you have none of them. So distributing Makefile.in or configure would be 
of no actual benefit.

An attempt to really accomodate Windows users would most likely end up 
much closer to CMake than to anything found in GNU packages today.