Russ Allbery wrote:
> Bob Proulx writes:
> > But another question to ask is if that is the case why not simply touch
> > all of the files to the same time after the patching and before the
> > make? That also forces everything to appear up to date too and doesn't
> &g
need AM_MAINTAINER_MODE to be added.
Sure, that also works. It just seems kind of silly to have to deceive
make rather than just removing the make rules that one doesn't want.
It only works if the source files are allowed to be writeable.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.t
Bob Proulx writes:
> But another question to ask is if that is the case why not simply touch
> all of the files to the same time after the patching and before the
> make? That also forces everything to appear up to date too and doesn't
> need AM_MAINTAINER_MODE to be added.
thers.)
But another question to ask is if that is the case why not simply
touch all of the files to the same time after the patching and before
the make? That also forces everything to appear up to date too and
doesn't need AM_MAINTAINER_MODE to be added.
Bob
> conceptually wrong exists; I live in a world where conceptually wrong is
> daily bread and I want a weapon against time waste.
>
>> But OTOH, I certainly do not want to encourage any new use of it: unless
>> I'm still missing something fundamental here, AM_MAINTAINE
Ineiev writes:
> On 02/08/2013 08:30 PM, Russ Allbery wrote:
>> Another place where the default behavior frequently breaks is if one is
>> applying a patch to both the generated file and the source file,
>> usually because one explicitly *doesn't* want to re-run Automake (often
>> because there's
On 02/08/2013 08:30 PM, Russ Allbery wrote:
Another place where the default behavior frequently breaks is if one is
applying a patch to both the generated file and the source file, usually
because one explicitly *doesn't* want to re-run Automake (often because
there's some incompatibility with th
immanuel litzroth writes:
> Once again... this is biting us too so we usually add the AM_MAINTAINER
> mode ourselves. This scenario is 100% recognizable and a major source of
> problems for us.
I also religiously use AM_MAINTAINER_MODE for all of my packages because I
always want to b
Once again... this is biting us too so we usually add the AM_MAINTAINER
mode ourselves. This scenario is 100% recognizable and a major source
of problems for us.
Immanuel
On Fri, Feb 8, 2013 at 12:37 AM, Diego Elio Pettenò
wrote:
> On 07/02/2013 19:47, Stefano Lattarini wrote:
> > So you want to
We have had a lot of problems with this in our company, where I have
to keep explaining the issues involved. So strong agreement here.
Immanuel
On Thu, Feb 7, 2013 at 6:17 PM, Diego Elio Pettenò
wrote:
> On 07/02/2013 16:18, Stefano Lattarini wrote:
> > (Side note: using AM_MAINTA
conceptually wrong is
daily bread and I want a weapon against time waste.
> But OTOH, I certainly do not want to encourage any new use of it: unless
> I'm still missing something fundamental here, AM_MAINTAINER_MODE is
> basically an hack to work around suboptimal practices or brokenn
gt;
> Yes, it's all solvable with more attention to details and similar, but
> since we care for stuff to at least behave, --disable-maintainer-mode is
> much nicer _to us_.
>
But still, it is conceptually wrong, because it suggests that having
incompletely specified dependenc
On 07/02/2013 19:47, Stefano Lattarini wrote:
> So you want to allow users to disable maintainer-mode rules in every
> package?
Yes. Where users here is "distribution packagers".
> Better risk an extra rebuild than to miss a required one IMVHO. Or
> understand why timestamps get mangled, and fix
build than to miss a required one IMVHO. Or
understand why timestamps get mangled, and fix that problem instead of
its symptoms (i.e., unnecessary rebuilds, in this case).
It may be that Automake maintainers do not understand the usages that
AM_MAINTAINER_MODE is actually being used for. This opti
On 02/07/2013 06:17 PM, Diego Elio Pettenò wrote:
> On 07/02/2013 16:18, Stefano Lattarini wrote:
>> (Side note: using AM_MAINTAINER_MODE these days is generally a bad idea
>> IMHO; we should find a way to deprecate its usage in documentation, and
>> eventually start warnin
On 07/02/2013 16:18, Stefano Lattarini wrote:
> (Side note: using AM_MAINTAINER_MODE these days is generally a bad idea
> IMHO; we should find a way to deprecate its usage in documentation, and
> eventually start warning at runtime if it is used -- and don't worry,
> with *no*
16 matches
Mail list logo
