This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New libffi release? Other misc issues.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]