Mail Archives: cygwin-apps/2002/04/29/18:15:59
----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
To: <cygwin-Apps AT cygwin DOT com>
> It's precisely the autotool version number that is the common reason
for
> checking autogenerated files into CVS. It eliminates the need for
other
> developers to have the same version of the autotools. For instance,
if
I disagree with this. It only eliminates that need on projects that have
static Makefile.am and configure.in's. I find that active projects,
almost invariably add files, with the few exceptions being things like
w32api that have tightly set limits from elsewhere.
> you require version 2.52 of configure.in for libgetopt++ then that
means
> that anyone who is cross-building on linux will need that version.
However,
> this version conflicts with things like gdb, binutils (I think), and
gcc.
We simply need a version that will run with automake 1.5 or greater.
That is, any developer building setup needs autoconf 2.13 or better
(I've put 2.53 in the configure.in's because of the devel scripts on
cygwin. I intend to do something about that when I have some spare time
to fiddle with specifying which version runs). And automake 1.5 or
better. And any libtool that will build static libs.
> to build them. It's simple to do that on cygwin if you have automake
and
> autoconf installed but it's not intuitively obvious.
Which is where a 'build-depends:' for setup.exe comes in. Click for the
source, get the support tools.
> It also seems inconsistent to me to use one philosophy in setup and
> another in a library used for setup.
>
> (Yes, I do know that libgetopt++ is intended as a general purpose
library)
I can see that. What I can do is make a copy of libgetopt++ into the
setup directory, rather than referencing the module. I was hesistant
about doing that, because that then makes me have to syncronise the two
locations, which is also a pain.
> I'm not going to issue an edict since I don't think it's a big enough
> deal. I just think that not including configure, Makefile.in, and
> Makefile are a barrier towards contribution. If you still don't want
to
> include them that's your call. I, personally, don't really want to
have
> a long discussion about the pros and cons.
Neither do I. I'll wait for Michael, Gary, Pavel and co to chime in.
They are the current non-Robert contributors, and it's *their* life I
want to make (as well as mine).
Rob
- Raw text -