v4l-utils migrated to autotools

v4l-utils migrated to autotools

[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.

Thanks,
Gregor

Re: v4l-utils migrated to autotools

[Hans de Goede]

Hi,

On 01/15/2012 10:37 PM, Gregor Jasny wrote:
> 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

Re: v4l-utils migrated to autotools

[Mauro Carvalho Chehab]

Em 15-01-2012 19:37, Gregor Jasny escreveu:
> 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.

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

Re: v4l-utils migrated to autotools

[Rémi Denis-Courmont]

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

<mchehab@redhat.com> 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)

> 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.



-- 

Rémi Denis-Courmont

http://www.remlab.net/

Re: v4l-utils migrated to autotools

[Mauro Carvalho Chehab]

Em 18-01-2012 10:31, Rémi Denis-Courmont escreveu:
> On Wed, 18 Jan 2012 10:19:24 -0200, Mauro Carvalho Chehab
> <mchehab@redhat.com> 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)
>> 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 <mchehab@redhat.com>
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 <mchehab@redhat.com>

diff --git a/configure.ac b/configure.ac
index 48428d1..6d3e76a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -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

Re: v4l-utils migrated to autotools

[Rémi Denis-Courmont]

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

<mchehab@redhat.com> wrote:

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

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

>> <mchehab@redhat.com> 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)

>>> 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.



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



-- 

Rémi Denis-Courmont

http://www.remlab.net/

Re: v4l-utils migrated to autotools

[Patrick Boettcher]

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
> 
> <mchehab@redhat.com> 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)
> 
> > 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/

Re: v4l-utils migrated to autotools

[Gregor Jasny]

On 1/18/12 1:44 PM, Patrick Boettcher wrote:
> 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

Re: v4l-utils migrated to autotools

[Rémi Denis-Courmont]

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

<pboettcher@kernellabs.com> 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.



-- 

Rémi Denis-Courmont

http://www.remlab.net/

Re: v4l-utils migrated to autotools

[Gregor Jasny]

On 1/18/12 1:19 PM, Mauro Carvalho Chehab wrote:
> 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.

> 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

Re: v4l-utils migrated to autotools

[Mauro Carvalho Chehab]

Em 18-01-2012 10:47, Gregor Jasny escreveu:
> On 1/18/12 1:19 PM, Mauro Carvalho Chehab wrote:
>> 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/

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

Ok, thanks!

>> 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

Re: v4l-utils migrated to autotools

[Gregor Jasny]

On 1/18/12 1:54 PM, Mauro Carvalho Chehab wrote:
> Em 18-01-2012 10:47, Gregor Jasny escreveu:
>> On 1/18/12 1:19 PM, Mauro Carvalho Chehab wrote:
>>> 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/

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

Re: v4l-utils migrated to autotools

[Mauro Carvalho Chehab]

Em 18-01-2012 11:02, Gregor Jasny escreveu:
> On 1/18/12 1:54 PM, Mauro Carvalho Chehab wrote:
>> Em 18-01-2012 10:47, Gregor Jasny escreveu:
>>> On 1/18/12 1:19 PM, Mauro Carvalho Chehab wrote:
>>>> 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/
> 
> 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


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

Re: v4l-utils migrated to autotools

[Theodore Kilgore]

On Wed, 18 Jan 2012, Mauro Carvalho Chehab wrote:

> Em 18-01-2012 11:02, Gregor Jasny escreveu:
> > On 1/18/12 1:54 PM, Mauro Carvalho Chehab wrote:
> >> Em 18-01-2012 10:47, Gregor Jasny escreveu:
> >>> On 1/18/12 1:19 PM, Mauro Carvalho Chehab wrote:
> >>>> 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/
> > 
> > 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

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