On Thu, Jun 20, 2019 at 07:10:54PM +0200, Fabiano Fidêncio wrote: > On Thu, Jun 20, 2019 at 7:05 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > > On Thu, Jun 20, 2019 at 06:42:29PM +0200, Pavel Hrdina wrote: > > > Few more notes that I've noticed: > > > > > > - There is a regression, with meson we no longer have generated RPM > > > spec files in tarball. > > > > Yep, that's desirable so users can do "rpmbuild -ta TARBALL", though > > note only the native spec is desired - not the generated mingw spec. > > > > > - With autotools there were some configure options: > > > --enable-vala [default check] > > > --enable-coverage [default no] > > > --with-usb-ids-path [default (internal)] > > > --with-pci-ids-path [default (internal)] > > > --enable-werror [default git ? yes : no ] > > > > Yep, we should keep at least the last 3 args. The coverage stuff coukd > > simply be auto-detected with no arg. I'm on the fence wrt whether we > > need a vala arg or not > > No, we shouldn't. > ``` > fidencio@laerte /tmp/osinfo-db-tools $ ./configure --enable-vala > --enable-coverage --with-usb-ids-path --with-pci-ids-path > --enable-werror > configure: WARNING: unrecognized options: --enable-vala, > --enable-coverage, --with-usb-ids-path, --with-pci-ids-path > ... > configure: WARNING: unrecognized options: --enable-vala, > --enable-coverage, --with-usb-ids-path, --with-pci-ids-path > ``` Oh right, this was leftover cruft that was in the libosinfo code originally that we mistakenly didn't delete. > About the --enable-werror, it's just a matter of passing -werror to meson. but this requires a developer opt-in - IMHO we really want to keep having werror always enabled when building from .git at least. We can do that without a flag if we're ok not providing a way to disable it when a .git dir exists. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
