automake-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_F


From: Stefano Lattarini
Subject: Re: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS
Date: Wed, 15 Jun 2011 23:56:07 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Wednesday 15 June 2011, Ralf Corsepius wrote:
> On 06/15/2011 07:57 PM, Eric Blake wrote:
> > On 06/15/2011 11:31 AM, Ralf Corsepius wrote:
> >>>> DISTCHECK_CONFIGURE_FLAGS is useful in situations when a plain
> >>>> "./configure" is not meaningful to a source tree, i.e. when a
> >>>> source-tree mandatorily requires some configuration argument.
> >>> Such a source-tree is violating GNU Coding Standards.
> >> a) DISTCHECK_CONFIGURE_FLAGS makes it compliant.
> > No, {AM_}DISTCHECK_CONFIGURE_FLAGS makes it possible for 'make
> > distcheck' to paper over the GCS violation.
> Your view - My view differs.
> > 'make distcheck' is not mandated by GCS.  Rather, it is a handy helper
> > to prove that the rest of things that _are_ mandated by GCS are obeyed.
> >   One of those GCS requirements is that './configure' in isolation do
> > something useful, rather than fail, if all prerequisite packages are
> > installed.
> >
> > http://www.gnu.org/software/autoconf/manual/standards.html#Configuration
> "...if all reprequiste packages are installed..." there are situations 
> where this is impossible or at least hard to implement.
> 
> C.f. what I wrote in my previous mail or think about making "make 
> distcheck" working for, say gcc or newlib ;-)
> 
> >> b) There are situations, in which it's technically very hard if not
> >> impossible to make automake's vanilla "make distcheck" functional.
> > And the fact that such cases exist, contrary to GCS, is why it is nice
> > of automake to give hooks to make 'make distcheck' easier to paper over
> > these shortcomings in GCS compliance in the meantime.
> Again, I disagree ... not doing so would make automake a toy, which 
> lacks contact to reality.
>
Let's not exaggerate.  It would "just" restrict and reduce the scope of
applicability of automake -- reduce it by an *unacceptable* amount, I
agree.  But we don't plan to go down that road, so don't worry.

> >>>    On the other
> >>> hand, automake strives to be useful to more than just GCS-compliant
> >>> packages.
> >> Agreed.
> > Sounds like we're in violent agreement, then :)
> Well, yes - religiously sticking with idealistic, non-realistic ideals 
> (which some people would call silly) doesn't help anybody.
> 
> In other words: IMO, automake is right in encouraging users to avod 
> DISTCHECK_CONFIGURE_FLAGS,
>
Actually, automake will discourage the use of AM_DISTCHECK_CONFIGURE_FLAGS
*by developers*, not of DISTCHECK_CONFIGURE_FLAGS by users.  This is
meant as a way to encourage developers to write packages where a vanilla
"./configure && make" just works.  But of course, automake will continue
to support AM_DISTCHECK_CONFIGURE_FLAGS for those rare packages where
the above is very difficult to attain.

> but it would be "beyond reason" for automake to abandon it.
>
I agree, but nobody is suggesting to abandon it!  On the other hand, my
patch added support for allowing customization by both the developer and
the user, and for having those customizations play nice together.

Regards,
  Stefano



reply via email to

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