public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Matthias Klose <doko@ubuntu.com>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anthony Green <green@moxielogic.com>, libffi-discuss@sourceware.org
Subject: Re: New libffi release? Other misc issues.
Date: Wed, 06 Feb 2013 12:25:00 -0000	[thread overview]
Message-ID: <51124B94.2020205@ubuntu.com> (raw)
In-Reply-To: <20130206102437.5390a499@skate>

Am 06.02.2013 10:24, schrieb Thomas Petazzoni:
>> 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).

well, GCC is most likely an exception, and libffi is shipped with GCC too. If
having the generated files within libffi helps reducing the delta, then why not
do it?.

  Matthias

      reply	other threads:[~2013-02-06 12:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-04 23:42 Thomas Petazzoni
2013-02-05  0:45 ` Luis Lavena
2013-02-05 22:41 ` Anthony Green
2013-02-06  9:24   ` Thomas Petazzoni
2013-02-06 12:25     ` Matthias Klose [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51124B94.2020205@ubuntu.com \
    --to=doko@ubuntu.com \
    --cc=green@moxielogic.com \
    --cc=libffi-discuss@sourceware.org \
    --cc=thomas.petazzoni@free-electrons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).