wdiff-bugs
[Top][All Lists]
Advanced

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

Re: [wdiff-bugs] Build problems fixed, please test for 0.5.4 release


From: Denver Gingerich
Subject: Re: [wdiff-bugs] Build problems fixed, please test for 0.5.4 release
Date: Sat, 23 Jun 2007 10:02:37 -0400

On 6/23/07, Santiago Vila <address@hidden> wrote:
On Sat, 23 Jun 2007, Denver Gingerich wrote:

> On 6/22/07, Santiago Vila <address@hidden> wrote:
> > Hi.
> >
> > The current code does not pass my test for well-behaved makefiles:
> >
> > cvs -z3 -d:pserver:address@hidden:/sources/wdiff co wdiff
> > cp -a wdiff wdiff.orig
> > cd wdiff
> > ./configure
> > make
> > make distclean
> > cd ..
> > diff wdiff.orig wdiff
> >
> > The output for the last commmand should be empty, but it's not:
> [...]
> > I believe it's the GNU standards who say this should be empty, but I'm not
> > completely sure. I would call it a highly desirable thing anyway.
>
> Does this work on the stock wdiff 0.5?

Yes. It worked on wdiff 0.5.

> What about 0.5g
> (http://wdiff.progiciels-bpi.ca/archives/wdiff-0.5g.tar.gz)?

On 0.5g I get this, after "./configure; make; make distclean":

Only in wdiff-0.5g/src: mdiff.1
Only in wdiff-0.5g/src: unify.1
Only in wdiff-0.5g/src: wdiff.1
Only in wdiff-0.5g: stamp-pot

so that part of the diff was introduced by 0.5g, but all the other stuff
has been introduced by the recent changes.

I will look into this to see why 0.5.90 works differently.  I think
the problem may be related to your issues with make (since it rebuilds
some of the Makefiles, etc.), but that should be verified.

Frankly, I think the current build system (using "touch" and similar things)
is too much hacky for a GNU official release. Sometimes I use that trick
on Debian packages because I need to make the Makefiles to believe
that I have not modified something in the Debian .diff.gz, but that
have been always a temporary hack until the next upstream "clean"
version which does not need any hacks.

Personally, I'm fine with keeping this hack in because it's for
somewhat of an intermediate release.  Once we remake the build system
for the package, these sorts of things should become a non-issue, but
I don't want to do that in this release because its intent is to be an
integration of 0.5g.  Please comment on whether you think this is too
hacky, especially if you have lots of experience with GNU packages.

Denver




reply via email to

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