> I'm not sure how if it impacts this particular change, but why don't
> we switch
> to AM_INIT_AUTOMAKE([foreign]) ? Since AUTHORS or ChangeLog are no
> longer
> static, it seems we are just causing ourselves pain by trying to work
> around
> auto* insisting those files exist.
> 
> Then again I don't know what benefits non-foreign gives us...

Interesting idea; reading the automake manual, I see:

https://www.gnu.org/software/automake/manual/automake.html#Strictness

foreign
    Automake will check for only those things that are absolutely required for 
proper operations. For instance, whereas GNU standards dictate the existence of 
a NEWS file, it will not be required in this mode. This strictness will also 
turn off some warnings by default (among them, portability warnings). The name 
comes from the fact that Automake is intended to be used for GNU programs; 
these relaxed rules are not the standard mode of operation. 

then further details here:
https://www.gnu.org/software/automake/manual/automake.html#Gnits

    The files INSTALL, NEWS, README, AUTHORS, and ChangeLog, plus one of 
COPYING.LIB, COPYING.LESSER or COPYING, are required at the topmost directory 
of the package.

    If the --add-missing option is given, automake will add a generic version 
of the INSTALL file as well as the COPYING file containing the text of the 
current version of the GNU General Public License existing at the time of this 
Automake release (version 3 as this is written, 
http://www.gnu.org/copyleft/gpl.html). However, an existing COPYING file will 
never be overwritten by automake.
    The options no-installman and no-installinfo are prohibited. 


Right now, we are relying on 'automake --add-missing' to generate our INSTALL,
so switching to 'foreign' would break that.  But it wouldn't be too hard
to check a static copy of INSTALL into libvirt.git if that's the only thing
in the way of us using a more relaxed automake mode.

-- 
Eric Blake   [email protected]    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

--
libvir-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to