On Mon, Feb 11, 2008 at 02:17:54PM +0100, Daniel Leidert wrote: > Am Montag, den 11.02.2008, 10:54 +0100 schrieb David Paleino: > > Il giorno Mon, 11 Feb 2008 10:53:48 +0100 > > Bas Wijnen <[EMAIL PROTECTED]> ha scritto: > > > > > I suggest to mandate "remove all generated files in the clean target" > > > (formulated in a way which includes "generated by upstream", not only > > > "generated by the build target), which implies "rebuild everything in > > > the build target". > > > > I fully agree with you here: the build target should also build Makefile.in > > from Makefile.am, for example. Thus we clean *.in, *.sub, *.guess, in the > > clean > > target. > > The files you mention belong to the maintainer-clean target.
Most of them, yes. In my Makefile.ams I have an "autoclean" target,
which really removes everything. Some things are installed by autotools
with the intention that you turn them into source files (INSTALL for
example). I want those removed as well, because they aren't source
files on my system.
> To remove them in the debian/rules clean target you would often have
> to repackage the source tarball,
What gave you that idea? What sort of change do you expect to need that
can't be done in the diff.gz?
> which often includes patching, because many autotools-based build
> environments do not fully implement maintainer-clean.
Except for packages where I am upstream, I don't think I know any
packages which have a proper autoclean target. Indeed, in such a case
Debian should do it by itself. Not that it's very hard. It's simply a
matter of:
AUTOJUNK = list of files to potentially remove
ifneq ($(wildcard ${AUTOJUNK},))
rm -r $(wildcard ${AUTOJUNK},)
endif
Or, if you're lazy, you can just use rm -rf. I prefer this method,
because -f hides more errors than just "file doesn't exist".
> Otherwise you would need to duplicate maintainer-clean in the
> debian/rules clean target (good luck with large source archives, maybe
> including even sub-projects!).
Your package plus its build-depends must contain the full source of
whatever is built. The source of every single generated file _must_
already be in your package anyway. If you can give an example of a
package which would need extra source files to build everything in it,
then please file a bug against it.
> You further need to build depend on the whole autotools chain +
> additional tools like gnome-doc-utils or intltool or ....
Not a big problem, and also very reasonable: if someone wants to build
this package from source, she does indeed need all those packages. If
a user wants to make changes to the source, those packages are needed
anyway to get those changes reflected in the package.
As a good example you can have a look at gnujump. I could have just
called configure and make. But I decided to run autotools during build.
I found that it needed autoconf-archive, plus an argument to the
autoconf invocation, to make it compile. If I would not have
regenerated configure during the build process, it would have been
easier for me. But when users would try to build the package from real
source, they would find that they couldn't. And they would need to find
out why. I think it is a Good Thing(tm) if Debian's build scripts can
be used as documentation for how a package can be built from source.
> We simply copy config.sub and config.guess into the build directory for
> some years now and I never observed any problem with this.
The mail you replied to was about such a problem, you even quoted it. I
just told you about a problem with gnujump. The whole reason we're
having this discussion is because there are problems with the current
approaches.
You are saying "Building from source means we need dependencies, and you
have to figure out how to build the program, and there are lots of
problems in general. Let's just use pre-built files instead."
This is of course entirely true. It is also true for every other
generated file. Why not pre-compile bash, put it in the diff.gz
uuencoded, and let debian/rules just uudecode it? It makes things much
easier, you don't get nasty build failures, and you don't need many
build-dependencies.
Let's for the moment ignore the architecture-specific problems of that
approach. I hope you agree with me that it still isn't an acceptable
way to package bash? Why do you want to allow it for
autotools-generated files?
> I'm really wondering why you want to make the situation complicated?
The "complication" that I'm adding is that I want to build things from
source. AFAIK that is something everyone agrees on as a Good Thing.
Only for some reason there is an exception for autotools.
> > And, as a sidenote, I've just faced this. I patched a Makefile.am,
> > and wasn't seeing any result.
>
> This project very probably used the AM_MAINTAINER_MODE macro. Enable the
> maintainer-mode with --enable-maintainer-mode.
You can't easily do that when using the Debian build system. And using
the Debian build system certaily should be an acceptable way of
generating custom Debian packages. For example, when I tested a patch
in meritous yesterday, I did:
apt-get source meritous
<add -ggdb3 to and remove dh_strip from debian/rules>
debuild
dpkg -i ../*deb
<test>
I'm not saying this is the only way to do things. But it certainly is
acceptable. Now in this case I was hacking debian/rules, which is fine.
But I want to be able to edit any source file. The quote above shows
that people sometimes wat to edit Makefile.am as well. I don't see any
reason why we shouldn't allow that.
> > I also had to patch Makefile.in. That's non-sense to me.
>
> Why do you patch Makefile.am?
Ehm, because you want to do things which are managed by it to be done
differently, perhaps?
> It just makes sense, when you manipulate or change macros (e.g. make
> libraries convenience libraries). If you just change a path or if you
> want to remove a binary from installation ... then simply patch
> Makefile.in directly.
"directly"? Sorry, changing the source is always the preferred thing to
do. "Go edit the generated file" may be an acceptable workaround in
some situations, but it is _never_ the proper way to do things.
An "exception" to this is when you turn the generated file into a source
file. Sometimes that makes sense, and in such a case editing it is
appropriate. But then the original source should be removed. This
situation can happen for generated images, for example. It never
happens for Makefile.in.
> There is often no reason to patch Makefile.am.
If a change to the Makefile is desired, then Makefile.am is the right
place to make that change. There is no problem when building from
source.
On Mon, Feb 11, 2008 at 03:09:52PM +0100, Daniel Leidert wrote:
> I even forgot some point: The scripts (often: autogen.sh) to
> (re-)create the build environment are normally only part of the
> upstream VCS but are not shipped with the source tarball.
IME they usually are, but not always, indeed.
> So even if the project fully implemented maintainer-clean, you would
> need to copy this file from the upstream VCS or write it yourself to
> recreate the build environment.
Yes. If it exists, you copy it from upstream so that it ends up in the
diff.gz, and you ask upstream if they would please consider adding it to
the distributed tarballs for the users' convenience. If it doesn't
exist, you write it yourself.
> But these scripts are sometimes more complicated than a simple call to
> autoheader, aclocal, autoconf and automake.
Indeed. I already referred to gnujump. I recently also had some
trouble getting ceferino to compile. I much prefer this trouble to be
on the Debian maintainer's shoulders, not the user's.
Compiling a program is also sometimes more complicated than a simple
call to make. That isn't enough reason to use pre-built files either,
is it?
> I think the idea to use the pure VCS source without any
> autotools-generated file creates much more issues than it maybe
> solves.
Why is this true for autotools-generated files, but not for
gcc-generated files?
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
signature.asc
Description: Digital signature
