v4l-utils migrated to autotools

DISCUSSION Gregor Jasny 6 participants 14 messages Jan 15, 2012 – Jan 18, 2012 Media (V4L/DVB)

Share & tools

Gregor Jasny

author

2012-01-15 21:37 UTC #0 lore raw

Hello,

I'm Gregor the Debian (and thus Ubuntu) Maintainer of v4l-utils. I took the challenge to convert the Makefile based build system into an autotools one. This weekend I polished the last bits and submitted my changes.

If you build v4l-utils from source, please clean your tree via "git clean" after the pull. Then make sure you have autotools, libtool and pkg-config installed. Bootstrap the autotools environment by calling "autoreconf -vfi". The rest is the usual configure && make && make install.

Thanks,
Gregor

Hans de Goede

2012-01-17 08:20 UTC #1 lore raw

Hi,

Quoted 11 lines · Gregor Jasny

Hello,
I'm Gregor the Debian (and thus Ubuntu) Maintainer of v4l-utils. I took the challenge to convert the Makefile based build system into an autotools one. This weekend I polished the last bits and submitted my changes.
If you build v4l-utils from source, please clean your tree via "git clean" after the pull. Then make sure you have autotools, libtool and pkg-config installed. Bootstrap the autotools environment by calling "autoreconf -vfi". The rest is the usual configure&& make&& make install.

Good work! And many thanks for working on this.

Regards,

Hans

Mauro Carvalho Chehab

2012-01-18 12:19 UTC #2 lore raw

In reply to Gregor Jasny

Em 15-01-2012 19:37, Gregor Jasny escreveu:

Quoted 11 lines

Hello,
I'm Gregor the Debian (and thus Ubuntu) Maintainer of v4l-utils. I took the challenge to convert the Makefile based build system into an autotools one. This weekend I polished the last bits and submitted my changes.
If you build v4l-utils from source, please clean your tree via "git clean" after the pull. Then make sure you have autotools, libtool and pkg-config installed. Bootstrap the autotools environment by calling "autoreconf -vfi". The rest is the usual configure && make && make install.

Nice job.

It would be nice to write at the INSTALL what dependencies are needed for the autotools to work, or, alternatively, to commit the files generated by the autoreconf -vfi magic spell there [1].

Not sure if it is possible, but it would be great if the build output would be less verbose. libtool adds a lot of additional (generally useless) messages, with makes harder to see the compilation warnings in the middle of all those garbage.

Thanks,
Mauro.

[1] this is one of the things I hate on those new autoconf stuff: the tools were supposed to detect the missing dependencies, but it doesn't detect the missing auto*/libtool packages. Worse than that, compiling those packages on an stable distro is generally a trouble, as they generally require recent versions of the tools. IMHO, it is somewhat broken by design. The option is to commit the autogenerated packages, in order to allow the poor user to compile it, but it can also be a trouble on stable distros, due to the autotools/libtool dependencies.

Quoted 7 lines

Thanks,
Gregor
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Rémi Denis-Courmont

2012-01-18 12:40 UTC #3 lore raw

On Wed, 18 Jan 2012 10:19:24 -0200, Mauro Carvalho Chehab

Quoted 3 lines · <[email protected]> wrote:

Not sure if it is possible, but it would be great if the build output
would be less verbose. libtool adds a lot of additional (generally

useless)

Quoted 3 lines

messages, with makes harder to see the compilation warnings in the
middle of all those garbage.

These days, automake has a silent mode that looks much like a kernel

compilation.

Signature · 3 lines

Rémi Denis-Courmont

http://www.remlab.net/

Mauro Carvalho Chehab

2012-01-18 12:43 UTC #4 lore raw

Em 18-01-2012 10:31, Rémi Denis-Courmont escreveu:

Quoted 11 lines

Quoted 2 lines · Mauro Carvalho Chehab
Not sure if it is possible, but it would be great if the build output would be less verbose. libtool adds a lot of additional (generally
useless)
Quoted 2 lines
messages, with makes harder to see the compilation warnings in the middle of all those garbage.
These days, automake has a silent mode that looks much like a kernel compilation.

Thanks for pointing it! I've enabled this with this small patch.

Regards,
Mauro.

commit 69378dc5285a5bac78e1e57cce34cc9af3855d52

Author: Mauro Carvalho Chehab <[email protected]>
Date:   Wed Jan 18 10:41:26 2012 -0200

autotools: allow enabling the silent-rules

With this change, it is now possible to do:
$ make V=0
or
$ ./configure --enable-silent-rules

in order to be less verbose.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

configure.ac +1 -0

index 48428d1..6d3e76a 100644
@@ -36,6 +36,7 @@ AC_CONFIG_FILES([Makefile
 AM_INIT_AUTOMAKE([1.9 no-dist-gzip dist-bzip2 -Wno-portability]) # 1.10 is needed for target_LIBTOOLFLAGS
 
 AM_MAINTAINER_MODE
+AM_SILENT_RULES
 
 # Checks for programs.
 AC_PROG_CXX

Rémi Denis-Courmont

2012-01-18 13:01 UTC #5 lore raw

On Wed, 18 Jan 2012 10:43:21 -0200, Mauro Carvalho Chehab

Quoted 26 lines · <[email protected]> wrote:

Em 18-01-2012 10:31, Rémi Denis-Courmont escreveu:
Quoted 12 lines
On Wed, 18 Jan 2012 10:19:24 -0200, Mauro Carvalho Chehab
Quoted 3 lines · <[email protected]> wrote:
Not sure if it is possible, but it would be great if the build output
would be less verbose. libtool adds a lot of additional (generally
useless)
Quoted 1 line
messages, with makes harder to see the compilation warnings in the
Quoted 9 lines
Quoted 1 line
middle of all those garbage.
These days, automake has a silent mode that looks much like a kernel
compilation.

Quoted 3 lines

Thanks for pointing it! I've enabled this with this
small patch.

You can even do AM_SILENT_RULES([yes]) if you want silence by default.

Signature · 3 lines

Rémi Denis-Courmont

http://www.remlab.net/

Patrick Boettcher

2012-01-18 12:44 UTC #6 lore raw

In reply to Rémi Denis-Courmont

Quoted 7 lines · On Wednesday 18 January 2012 13:31:01 Rémi Denis-Courmont wrote:

On Wed, 18 Jan 2012 10:19:24 -0200, Mauro Carvalho Chehab
Quoted 3 lines · <[email protected]> wrote:
Not sure if it is possible, but it would be great if the build output would be less verbose. libtool adds a lot of additional (generally

Quoted 7 lines

useless)
Quoted 2 lines
messages, with makes harder to see the compilation warnings in the middle of all those garbage.
These days, automake has a silent mode that looks much like a kernel compilation.

I missed the first message of this thread, that's why I hijacked it here and it is short:

I love cmake and can't understand why people are not preferring it over autotools for user-space applications and conditional+configurable builds.

I hope my mail is not too off-topic.

regards,
--
Patrick Boettcher

Kernel Labs Inc.
http://www.kernellabs.com/

Gregor Jasny

author

2012-01-18 12:56 UTC #7 lore raw

Quoted 8 lines · Patrick Boettcher

I missed the first message of this thread, that's why I hijacked it here and it is short:
I love cmake and can't understand why people are not preferring it over autotools for user-space applications and conditional+configurable builds.
I hope my mail is not too off-topic.

My first attempt to add a sane buildsystem used cmake, too:
https://github.com/gjasny/v4l-utils-cmake

But Hans (de Goede) preferred something more 'standard'. So I learned autofoo. And I must admit it really got better during the years.

And packaging is also easy:
http://bazaar.launchpad.net/~libv4l/+junk/packaging/view/head:/rules

Thanks,
Gregor

Rémi Denis-Courmont

2012-01-18 13:02 UTC #8 lore raw

In reply to Patrick Boettcher

On Wed, 18 Jan 2012 13:44:09 +0100, Patrick Boettcher

Quoted 5 lines · <[email protected]> wrote:

I love cmake and can't understand why people are not preferring it over
autotools for user-space applications and conditional+configurable
builds.

In my experience, cmake sucks at cross-compilation. It is also rather

limited when it comes to compiling libraries, as opposed to libtool.

Signature · 3 lines

Rémi Denis-Courmont

http://www.remlab.net/

Gregor Jasny

author

2012-01-18 12:47 UTC #9 lore raw

In reply to Mauro Carvalho Chehab

Quoted 3 lines · Mauro Carvalho Chehab

It would be nice to write at the INSTALL what dependencies are needed for the autotools to work, or, alternatively, to commit the files generated by the autoreconf -vfi magic spell there [1].

The end user gets a tarball created with "make dist" which contains all the m4 files.

For the developers I will list the dependencies (autotools-dev, pkgconfig and libtool) explicitely.

Quoted 4 lines

Not sure if it is possible, but it would be great if the build output would be less verbose. libtool adds a lot of additional (generally useless) messages, with makes harder to see the compilation warnings in the middle of all those garbage.

I will add the AM_SILENT_RULES option later.

Thanks,
Gregor

Mauro Carvalho Chehab

2012-01-18 12:54 UTC #10 lore raw

Em 18-01-2012 10:47, Gregor Jasny escreveu:

Quoted 6 lines · Mauro Carvalho Chehab

Quoted 3 lines
It would be nice to write at the INSTALL what dependencies are needed for the autotools to work, or, alternatively, to commit the files generated by the autoreconf -vfi magic spell there [1].
The end user gets a tarball created with "make dist" which contains all the m4 files.

Ah, ok. It probably makes sense then to add some scripting at the server to do a daily build, as the tarballs aren't updated very often. They're updated only at the sub-releases:
http://linuxtv.org/downloads/v4l-utils/

Quoted 1 line

For the developers I will list the dependencies (autotools-dev, pkgconfig and libtool) explicitely.

Ok, thanks!

Quoted 6 lines

Quoted 4 lines
Not sure if it is possible, but it would be great if the build output would be less verbose. libtool adds a lot of additional (generally useless) messages, with makes harder to see the compilation warnings in the middle of all those garbage.
I will add the AM_SILENT_RULES option later.

Just added it, and fixed two warnings I was not able to notice before, due to the excess of fast-scrolling messages that were appearing when compiling it here ;)

Thanks,
Mauro

Gregor Jasny

author

2012-01-18 13:02 UTC #11 lore raw

Quoted 6 lines · Mauro Carvalho Chehab

Em 18-01-2012 10:47, Gregor Jasny escreveu:
Quoted 5 lines · Mauro Carvalho Chehab
Quoted 3 lines
It would be nice to write at the INSTALL what dependencies are needed for the autotools to work, or, alternatively, to commit the files generated by the autoreconf -vfi magic spell there [1].

Quoted 6 lines

Quoted 1 line
The end user gets a tarball created with "make dist" which contains all the m4 files.
Ah, ok. It probably makes sense then to add some scripting at the server to do a daily build, as the tarballs aren't updated very often. They're updated only at the sub-releases:
http://linuxtv.org/downloads/v4l-utils/

Judging from the upside-down reports: not the lack of a buildable tarball but the lack of updated distribution packages is a problem. For Ubuntu we have a PPA repository with nightly builds:

https://launchpad.net/~libv4l/+archive/development

Do you have similar infrastructure for Fedora / RedHat, too?

Thanks,
Gregor

Mauro Carvalho Chehab

2012-01-18 14:52 UTC #12 lore raw

Em 18-01-2012 11:02, Gregor Jasny escreveu:

Quoted 14 lines · Mauro Carvalho Chehab

Quoted 6 lines
Em 18-01-2012 10:47, Gregor Jasny escreveu:
Quoted 5 lines · Mauro Carvalho Chehab
Quoted 3 lines
It would be nice to write at the INSTALL what dependencies are needed for the autotools to work, or, alternatively, to commit the files generated by the autoreconf -vfi magic spell there [1].
Quoted 6 lines
Quoted 1 line
The end user gets a tarball created with "make dist" which contains all the m4 files.
Ah, ok. It probably makes sense then to add some scripting at the server to do a daily build, as the tarballs aren't updated very often. They're updated only at the sub-releases:
http://linuxtv.org/downloads/v4l-utils/

Quoted 5 lines

Judging from the upside-down reports: not the lack of a buildable tarball but the lack of updated distribution packages is a problem. For Ubuntu we have a PPA repository with nightly builds:
https://launchpad.net/~libv4l/+archive/development
Do you have similar infrastructure for Fedora / RedHat, too?

There are two separate issues here:

1) users that just get the distro packages.

For them, the updated distro packages is the issue.

For those, it is very good to have v4l-utils properly packaged on Ubuntu. Thanks for that!

Hans is maintaining v4l-utils at Fedora. I don't think he's currently using the -git unstable versions at Fedora Rawhide (the Fedora under development distro). Yet, every time a new release is lauched, he updates the packages for Fedora.

So, I think that this is now properly covered with Fedora and Ubuntu (also Debian?). I think that Suse is also doing something similar.

2) users that are testing the neat features that the newest package has.

This covers most of the 900+ subscribers of the linux-media ML.

Those users, in general, don't care much about the distro packages. They just want to download the latest sources and compile, in order to test the drivers/tools, and provide us feedback. We want to make life easier for them, as their test is very important for us to detect, in advance, when some regression is happened somewhere.

For those users, it may make sense to have a daily tarball or some user-friendly scripting that would allow them to easily clone the git tree and use it.

Regards,
Mauro

Quoted 7 lines

Thanks,
Gregor

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Theodore Kilgore

2012-01-18 16:34 UTC #13 lore raw

Quoted 48 lines · Mauro Carvalho Chehab

Em 18-01-2012 11:02, Gregor Jasny escreveu:
Quoted 14 lines · Mauro Carvalho Chehab
Quoted 6 lines
Em 18-01-2012 10:47, Gregor Jasny escreveu:
Quoted 5 lines · Mauro Carvalho Chehab
Quoted 3 lines
It would be nice to write at the INSTALL what dependencies are needed for the autotools to work, or, alternatively, to commit the files generated by the autoreconf -vfi magic spell there [1].
Quoted 6 lines
Quoted 1 line
The end user gets a tarball created with "make dist" which contains all the m4 files.
Ah, ok. It probably makes sense then to add some scripting at the server to do a daily build, as the tarballs aren't updated very often. They're updated only at the sub-releases:
http://linuxtv.org/downloads/v4l-utils/
Quoted 5 lines
Judging from the upside-down reports: not the lack of a buildable tarball but the lack of updated distribution packages is a problem. For Ubuntu we have a PPA repository with nightly builds:
https://launchpad.net/~libv4l/+archive/development
Do you have similar infrastructure for Fedora / RedHat, too?
There are two separate issues here:
1) users that just get the distro packages.
For them, the updated distro packages is the issue.
For those, it is very good to have v4l-utils properly packaged on Ubuntu. Thanks for that!
Hans is maintaining v4l-utils at Fedora. I don't think he's currently using the -git unstable versions at Fedora Rawhide (the Fedora under development distro). Yet, every time a new release is lauched, he updates the packages for Fedora.
So, I think that this is now properly covered with Fedora and Ubuntu (also Debian?). I think that Suse is also doing something similar.
2) users that are testing the neat features that the newest package has.
This covers most of the 900+ subscribers of the linux-media ML.
Those users, in general, don't care much about the distro packages. They just want to download the latest sources and compile, in order to test the drivers/tools, and provide us feedback. We want to make life easier for them, as their test is very important for us to detect, in advance, when some regression is happened somewhere.

Quoted 6 lines

For those users, it may make sense to have a daily tarball or some user-friendly scripting that would allow them to easily clone the git tree and use it.
Regards,
Mauro

As one of the people who comes under category (2) above, let me add a couple of comments, here.

First, I was unaware of these changes until I found out about them the hard way, a few days ago. Namely, I did a "git pull" and added the new stuff to my working copy, then could not compile anything. The error I got said that config.h is missing. Well, it took me all of about 5 minutes to figure out that I had better re-read the Imstall file, which made things totally clear. Run autoconf. Been there with other projects, done that. No problems. I only saw some mail on the list about the changeover a couple of days after that, and had a chuckle.

Second, it is no big deal. Autoconf works quite nicely, so what is the problem, exactly? I see not much need for "a daily tarball or some user-friendly scripting" to "fix" something which does not appear to be a problem. Well, there is a problem, but I do not see it as a serious one. The problem is that one's tools have to be up to date. That is up to the distro. But it is probably well known that some distros are better at keeping up with things like this than are others.

Theodore Kilgore