edi at gmx
Jul 7, 2004, 9:00 PM
Post #11 of 14
(1243 views)
Permalink
|
Moin James!
James Ralston schrieb am Wednesday, den 07. July 2004:
> > > But autoconf/automake makes it a lot easier to make packages
> > > (RPMs, .debs, etc.), including steps such as passing
> >
> > Nonsense.
>
> That wasn't a hypothetical statement; it was a statement of fact. I
A self-made fact!
> packaged vpnc as an RPM, and it was more difficult to do so because
> vpnc didn't support autoconf/automake.
I packaged it as DEB and I disagree with you. Neither did I hear any
complaints from the SuSE maintainer, and fellow BSD maintainer seem to
have the same opinion as me.
> > Who said that we need them? Where would be the big difference
> > between setting them via configure options or make options.
>
> Because setting them via configure options is the *expected thing to
Expected by whom? What is the difference between running "./configure ;
make install" and "make install"? Yes, it is only the missing configure
run which costs CPU time and extra space for no reason. And also adds
more complexity that tends to break (due to higher failure probability)
and is not adaptive to new environment (we have enough trouble with
obsolete autotools crap in Debian packages where support for amd64 or
mipsel was just missing).
> do*. RPM's %configure and %install macros, for example, will simply
> Do The Right Thing for any package that supports autoconf:
>
> %build
> %configure
> %__make
>
> %install
> %__make DESTDIR="${RPM_BUILD_ROOT}" install
What has autoconf to do with all that? It is a matter of few lines to
add a "install" rule to the current Makefile; why do you insist on
getting a monster to create this simple rule?
> Yes, you could manually patch vpnc's Makefile to support DESTDIR. But
> this is the kind of thing that autoconf will take care of for you.
Really? I think it will be much simpler to write the stuff down instead
of fiddling around with autoconf.
> Why not take a small amount of effort (which I volunteered!) to add
> autoconf/automake support now, so that you don't have to worry about
> build again?
The time costs of this effort are not the only problem, see below.
> Not "another" way; the *preferred* way.
>
> And why does it matter if the autoconf/automake stuff is larger than
> the codesize? A few extra KB in the package isn't going to matter.
"few"? Oh please, I just took the next random package using autoconf
(lufs) and (oh wonder) there is a configure script (plus related stuff)
with 700kB size. Do we really need a such beast for a package with less
than 200kB code size?
> > This is pointless unless autoconf can download and install
> > dependencies for them.
>
> No, it's not: being told that you need to install package foo is more
> helpful than having the compilation of one of the source files fail
> because a function from the missing package wasn't available.
*cough* The error message is more helpfull then README which you need to
read anyways?
> Besides, as Nicolas pointed out, firing off a *build* should not
> automatically download or install *anything*. (It wouldn't work with
It was just a counter-argument to the claim that autoconf makes things
"easier". And you admit that this is often not the case.
> > > Also, it might not matter to you, but autoconf/automake makes it
> > > very easy for software authors to make a distribution package from
> > > a development repository (e.g. CVS), just by running "make
> > > distribution".
> >
> > Eh? Run "make release" please.
>
> But "make distribution" is the standard autoconf/automake target. Why
Well, running "win" was the standard method to start Windows. What's the
point?
> not just use autoconf? Why reinvent the wheel (with a different
> name)?
a) because it is already there
b) because it costs less than 10 lines of Makefile code
> > People know how to start Windows to play games. So what?!
>
> So you believe every single software package in existence should have
> completely different, manually-generated Makefiles, with no agreement
> on standard build procedures and target names?
I believe in the method of using the right method for each thing.
Consistency makes sense on large packages, but not here.
> > > If you have a specific reasons for *not* wanting to use
> > > autoconf/automake, that's fine. But since having vpnc use
> > > autoconf/automake would make my life easier (as I build RPMs for
> > > most software I use), I thought I'd offer to add it.
> >
> > Which problem would autoconf solve for you?
>
> All of the ones I've outlined above.
You did not outline real problems, only hypothetical ones (like missing
of the "distribution" rule which you like) or self-made ones. As
packager and initially user, I am/was perfectly happy with the Makefile.
> I ask again: what problems would adding autoconf/automake support
> *add*? If we can't think of any, and Maurice is willing to use it,
> why shouldn't Maurice take me up on my offer?
I think it's extra work and we are students without much spare time and
such changes require some time to be checked in. And there are still no
concrete advantages, you repeat the old non-arguments.
Regards,
Eduard.
--
Der Atheismus ist ein Zeichen, da? man die Religion ernst nimmt.
-- Sir Karl Raimund Popper
|
