Re: New libffi release? Other misc issues.

[Thomas Petazzoni <thomas dot petazzoni at free-electrons dot com>]

Dear Anthony Green,

On Tue, 5 Feb 2013 17:41:40 -0500, Anthony Green wrote:

> Yes, I plan on making a release soon.  I wanted to make one important
> change first... see below for details.

Ah, nice!

> >  2) The Git repository of libffi contains a generated configure script.
> >  This is generally not considered a really good practice in terms of
> >  autotools usage. Normally, the files generated by autoconf/automake
> >  shouldn't be kept under version control. And in addition to that, the
> >  configure script that comes in the current Git version has a flaw: it
> >  doesn't generate the libffi.pc file from the libffi.pc.in template.
> 
> I'll fix the libffi.pc file issue.  I just noticed this myself.

Ok.

> As for committing the generated files.. I'm going to keep doing that
> for now.  I come by this honestly enough, as I believe that committing
> generated files was a best-practice for many years (see gcc, gdb,
> etc).  I'm not sure why it is frowned upon now.  It can be a pain to
> track down the right versions of the autotools to generate supported
> output.

What usually happens is that the configure/Makefile.in generated by
autoconf/automake are not in version control, but they are generated
and kept in release tarballs. So "normal" users have generated files so
they don't have to bother with autoconf/automake version issues. Only
"developers" who want to make changes to libffi have to use the right
versions, and it's not usually the biggest problem. These days, the
autoconf/automake language is fairly stable (not completely, of
course). In Buildroot (an embedded Linux build system), we have only a
single version of autoconf/automake/libtool that we use to autoreconf a
fairly significant number of packages coming from various upstreams,
and it generally works OK (with a few exceptions, of course).

I think not having configure/Makefile.in under version control is the
most common practice. See
http://www.openismus.com/documents/linux/automake/automake.shtml:

    Most projects kept in version control have an autogen.sh script
    that runs everything up to the configure step. This is done to
    provide a standard means for generating the build files from
    scratch, as generated files should never be put under version
    control. Release tarballs ship with pre-generated configure and
    Makefile.in files, so that the installer does not need to have
    autoconf or automake installed.

> >  3) There is an issue with the latest Git version as compared to the
> >  stable libffi 3.0.11 version: the libffi.pc gets generated in the
> >  source tree at configure time (once the configure script is
> >  regenerated), but "make install" doesn't install it. Would it be
> >  possible to fix this?
> 
> Yes.

Excellent, thanks!

> >  4) Is there a reason for libffi to install its headers
> >  in /usr/lib/libffi-<version>/include/ ? This is really a non-standard
> >  location compared to just /usr/include or /usr/include/libffi.
> >  Wouldn't it make sense to use a more standard behavior here?
> 
> This is the "one change" I was referring to up above.
> 
> I won't go into all of the reasons this was done, but I do want to
> change it.  I was hoping to change it for the next release, but I've
> decided not to bother yet.  I'll need some help on the PowerPC ports
> (sorting through compiler-defined macros, testing), and I can tell
> right now that it will take some doing to get right.

Ok.

> I'm going to make a release candidate tarball tomorrow for testing.

Ok, great. I'll try to give it a test then.

Thanks again,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com