Re: RFS: evilvte (updated package) - lightweight terminal emulator
* Wen-Yen Chuang <caleb@calno.com> [080527 15:27]:
> > * You do not build with the build flags suggested by policy (-O2 -g)
> Done.
> And it also supports DEB_BUILD_OPTIONS now.
While your solution works, I'd suggest setting OPTFLAGS instead.
Currently it is a bit confusing to have first and -Os and then an
overwriting -O2 -g later.
> > * your debian/rules is not parallel-clean (i.e. it might fail with -j2)
>
> I believe it is OK in evilvte, because the patches can be unpatched
> before or after "make clean".
>
> I have googled but did not find better way than "clean: clean1 unpatch".
> Can you give me some hint or a demo diff.gz?
You have to make sure the unpatch target depends on your clean target.
The easiest way is to just add a new dependency to the existing target,
like this:
unpatch: clean1
clean: unpatch
clean1:
[... as usual ...]
This has the disadvantage that it does not fail if the real unpatch rule
vanishes and may be a bit of confusing (though that might be cured with
a comment).
the other possiblity is to call make with the other target, like
clean:
dh_testdir
dh_testroot
[... usual stuff]
$(MAKE) unpatch
dh_clean
Though I agree with evilvte it is no real problem as thoe two are
commutative.
More annoying is that it call ./configure from "$(MAKE) clean" all the time.
perhaps you should just touch src/config.o before calling $(MAKE) clean.
(as whatever it would write itself to that file, that would already be
to late to be of effect in that make invocation).
> > * upstream Makefile has some bug causing the source to be compiled
> > multiple times (one time in build and again in binary)
>
> I tried several methods but finds no good way to pass the second
> compilation.
> I admit that the "make" process of upstream is very weird.
Looking again at it, I think it is not even upstreams fault but you have
made some mistakes, because your debian/rules makes make believe it has
to always remake the stuff because of multiple problems (each of would
suffice):
Your rule calling configure[1] depends on patch, which is a phony rule.
Thus make will each time it looks if build is up to date first call
patch again and then all the rules to follow after it. You should
depend on an actually generated file instead (best $(QUILT_STAMPFN)).
Your rule calling configure claims to generate config.status. But the
configure upstream produces does not do so, but a file src/config.o.
Thus you should use that instead of config.status.
With those two changes, the program is only build one time.
(There is still a bug in upstream's Makefile as it uses the phone
parsecfg target as prerequisite to evilvte, but that does not effect
the Debian package because of another bug in upstream's Makefile (install
not depending on all)).
Another little issue: configure calls pkg-config, but you do not
build-depend on that. That does not show any visible problems right
now because one of the depended on by build-dependencies library
erranously depends on pkg-config. If you use it directly, you should
build-depend on it directly, to avoid problems when the dependencies
of the build-dependencies change some time in the future.
Hochachtungsvoll,
Bernhard R. Link
[1] which you should limit to the actual used parameters really.
Otherwise I guess others might be confused by the parameters not in any
effect, too.
Reply to: