Re: [Xen-devel] [PATCH v4 13/16] Regenerate autotools files

2020-01-22 Thread Lars Kurth 


On 21/01/2020, 21:29, "Rich Persaud"  wrote:

On Jan 21, 2020, at 15:58, Marek Marczykowski-Górecki 
 wrote:
> 
> On Wed, Jan 15, 2020 at 04:57:29PM -0500, Rich Persaud wrote:
 On Jan 14, 2020, at 21:42, Marek Marczykowski-Górecki 
 wrote:
>>> Since we have those generated files committed to the repo (why?!),
>>> update them after changing configure.ac.
>> 
>> Is there any reason not to remove the generated configure files?  A 
developer using generated files on system B would be incorporating 
configuration assumptions from system A where the configure script was 
generated.  If we are going to ship configure scripts, do we need to document a 
"system A" reference distro/environment where all configure scripts from Xen 
will be generated?
>> 
>> 
>> Other notes:
>> 
>> 1.  Debian autoreconf works in the Xen root directory, but the default 
OpenEmbedded autoreconf uses Gnu libtoolize and fails because some Xen build 
subdirectories don't have configure.ac/.in.   
>> 
>> 2.  If OpenEmbedded autoreconf is run only in the tools directory (where 
it works and generates a new tools configure), then root configure (generated 
from older configure.ac) will silently ignore the newer tools configure and 
write config.h _without_ tools-specific config, such as the vchan QMP proxy.
>> 
>> 3. If autoreconf runs successfully in the root directory, then 
tools-specific configure is correctly generated and everything works as 
expected.
>> 
>> This silent failure could be avoided by deleting the generated configure 
scripts.  There may be other failure modes for using System A generated scripts 
on downstream build system B.
> 
> Yes, I think general good practices are:
> 1. don't keep generated autotools files in version control system
> 2. generate them into release tarballs

A potential topic for the next Xen community call:  can we delete generated 
autotools files from the Xen tree and update the release process to 
generate+bundle them with release tarballs?

I am happy to put this on the agenda, if someone reminds me closer to the time
Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 13/16] Regenerate autotools files

2020-01-21 Thread Rich Persaud 
On Jan 21, 2020, at 15:58, Marek Marczykowski-Górecki 
 wrote:
> 
> On Wed, Jan 15, 2020 at 04:57:29PM -0500, Rich Persaud wrote:
 On Jan 14, 2020, at 21:42, Marek Marczykowski-Górecki 
  wrote:
>>> Since we have those generated files committed to the repo (why?!),
>>> update them after changing configure.ac.
>> 
>> Is there any reason not to remove the generated configure files?  A 
>> developer using generated files on system B would be incorporating 
>> configuration assumptions from system A where the configure script was 
>> generated.  If we are going to ship configure scripts, do we need to 
>> document a "system A" reference distro/environment where all configure 
>> scripts from Xen will be generated?
>> 
>> 
>> Other notes:
>> 
>> 1.  Debian autoreconf works in the Xen root directory, but the default 
>> OpenEmbedded autoreconf uses Gnu libtoolize and fails because some Xen build 
>> subdirectories don't have configure.ac/.in.   
>> 
>> 2.  If OpenEmbedded autoreconf is run only in the tools directory (where it 
>> works and generates a new tools configure), then root configure (generated 
>> from older configure.ac) will silently ignore the newer tools configure and 
>> write config.h _without_ tools-specific config, such as the vchan QMP proxy.
>> 
>> 3. If autoreconf runs successfully in the root directory, then 
>> tools-specific configure is correctly generated and everything works as 
>> expected.
>> 
>> This silent failure could be avoided by deleting the generated configure 
>> scripts.  There may be other failure modes for using System A generated 
>> scripts on downstream build system B.
> 
> Yes, I think general good practices are:
> 1. don't keep generated autotools files in version control system
> 2. generate them into release tarballs

A potential topic for the next Xen community call:  can we delete generated 
autotools files from the Xen tree and update the release process to 
generate+bundle them with release tarballs?

Rich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 13/16] Regenerate autotools files

2020-01-21 Thread Marek Marczykowski-Górecki 
On Wed, Jan 15, 2020 at 04:57:29PM -0500, Rich Persaud wrote:
> > On Jan 14, 2020, at 21:42, Marek Marczykowski-Górecki 
> >  wrote:
> > Since we have those generated files committed to the repo (why?!),
> > update them after changing configure.ac.
> 
> Is there any reason not to remove the generated configure files?  A developer 
> using generated files on system B would be incorporating configuration 
> assumptions from system A where the configure script was generated.  If we 
> are going to ship configure scripts, do we need to document a "system A" 
> reference distro/environment where all configure scripts from Xen will be 
> generated?
> 
> 
> Other notes:
> 
> 1.  Debian autoreconf works in the Xen root directory, but the default 
> OpenEmbedded autoreconf uses Gnu libtoolize and fails because some Xen build 
> subdirectories don't have configure.ac/.in.   
> 
> 2.  If OpenEmbedded autoreconf is run only in the tools directory (where it 
> works and generates a new tools configure), then root configure (generated 
> from older configure.ac) will silently ignore the newer tools configure and 
> write config.h _without_ tools-specific config, such as the vchan QMP proxy.
> 
> 3. If autoreconf runs successfully in the root directory, then tools-specific 
> configure is correctly generated and everything works as expected.
> 
> This silent failure could be avoided by deleting the generated configure 
> scripts.  There may be other failure modes for using System A generated 
> scripts on downstream build system B.

Yes, I think general good practices are:
1. don't keep generated autotools files in version control system
2. generate them into release tarballs

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 13/16] Regenerate autotools files

2020-01-15 Thread Rich Persaud 
> On Jan 14, 2020, at 21:42, Marek Marczykowski-Górecki 
>  wrote:
> Since we have those generated files committed to the repo (why?!),
> update them after changing configure.ac.

Is there any reason not to remove the generated configure files?  A developer 
using generated files on system B would be incorporating configuration 
assumptions from system A where the configure script was generated.  If we are 
going to ship configure scripts, do we need to document a "system A" reference 
distro/environment where all configure scripts from Xen will be generated?


Other notes:

1.  Debian autoreconf works in the Xen root directory, but the default 
OpenEmbedded autoreconf uses Gnu libtoolize and fails because some Xen build 
subdirectories don't have configure.ac/.in.   

2.  If OpenEmbedded autoreconf is run only in the tools directory (where it 
works and generates a new tools configure), then root configure (generated from 
older configure.ac) will silently ignore the newer tools configure and write 
config.h _without_ tools-specific config, such as the vchan QMP proxy.

3. If autoreconf runs successfully in the root directory, then tools-specific 
configure is correctly generated and everything works as expected.

This silent failure could be avoided by deleting the generated configure 
scripts.  There may be other failure modes for using System A generated scripts 
on downstream build system B.

Rich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 13/16] Regenerate autotools files

2020-01-14 Thread Marek Marczykowski-Górecki 
Since we have those generated files committed to the repo (why?!),
update them after changing configure.ac.

Signed-off-by: Marek Marczykowski-Górecki 
---
 configure | 14 +-
 docs/configure| 14 +-
 stubdom/configure | 14 +-
 tools/config.h.in |  3 +++
 tools/configure   | 46 --
 5 files changed, 34 insertions(+), 57 deletions(-)

diff --git a/configure b/configure
index 83f84b0..e5d14b7 100755
--- a/configure
+++ b/configure
@@ -644,7 +644,6 @@ infodir
 docdir
 oldincludedir
 includedir
-runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
@@ -723,7 +722,6 @@ datadir='${datarootdir}'
 sysconfdir='${prefix}/etc'
 sharedstatedir='${prefix}/com'
 localstatedir='${prefix}/var'
-runstatedir='${localstatedir}/run'
 includedir='${prefix}/include'
 oldincludedir='/usr/include'
 docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
@@ -976,15 +974,6 @@ do
   | -silent | --silent | --silen | --sile | --sil)
 silent=yes ;;
 
-  -runstatedir | --runstatedir | --runstatedi | --runstated \
-  | --runstate | --runstat | --runsta | --runst | --runs \
-  | --run | --ru | --r)
-ac_prev=runstatedir ;;
-  -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
-  | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
-  | --run=* | --ru=* | --r=*)
-runstatedir=$ac_optarg ;;
-
   -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
 ac_prev=sbindir ;;
   -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1122,7 +,7 @@ fi
 for ac_var in  exec_prefix prefix bindir sbindir libexecdir datarootdir \
datadir sysconfdir sharedstatedir localstatedir includedir \
oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
-   libdir localedir mandir runstatedir
+   libdir localedir mandir
 do
   eval ac_val=\$$ac_var
   # Remove trailing slashes.
@@ -1275,7 +1264,6 @@ Fine tuning of the installation directories:
   --sysconfdir=DIRread-only single-machine data [PREFIX/etc]
   --sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com]
   --localstatedir=DIR modifiable single-machine data [PREFIX/var]
-  --runstatedir=DIR   modifiable per-process data [LOCALSTATEDIR/run]
   --libdir=DIRobject code libraries [EPREFIX/lib]
   --includedir=DIRC header files [PREFIX/include]
   --oldincludedir=DIR C header files for non-gcc [/usr/include]
diff --git a/docs/configure b/docs/configure
index fdfc110..598813d 100755
--- a/docs/configure
+++ b/docs/configure
@@ -634,7 +634,6 @@ infodir
 docdir
 oldincludedir
 includedir
-runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
@@ -711,7 +710,6 @@ datadir='${datarootdir}'
 sysconfdir='${prefix}/etc'
 sharedstatedir='${prefix}/com'
 localstatedir='${prefix}/var'
-runstatedir='${localstatedir}/run'
 includedir='${prefix}/include'
 oldincludedir='/usr/include'
 docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
@@ -964,15 +962,6 @@ do
   | -silent | --silent | --silen | --sile | --sil)
 silent=yes ;;
 
-  -runstatedir | --runstatedir | --runstatedi | --runstated \
-  | --runstate | --runstat | --runsta | --runst | --runs \
-  | --run | --ru | --r)
-ac_prev=runstatedir ;;
-  -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
-  | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
-  | --run=* | --ru=* | --r=*)
-runstatedir=$ac_optarg ;;
-
   -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
 ac_prev=sbindir ;;
   -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1110,7 +1099,7 @@ fi
 for ac_var in  exec_prefix prefix bindir sbindir libexecdir datarootdir \
datadir sysconfdir sharedstatedir localstatedir includedir \
oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
-   libdir localedir mandir runstatedir
+   libdir localedir mandir
 do
   eval ac_val=\$$ac_var
   # Remove trailing slashes.
@@ -1263,7 +1252,6 @@ Fine tuning of the installation directories:
   --sysconfdir=DIRread-only single-machine data [PREFIX/etc]
   --sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com]
   --localstatedir=DIR modifiable single-machine data [PREFIX/var]
-  --runstatedir=DIR   modifiable per-process data [LOCALSTATEDIR/run]
   --libdir=DIRobject code libraries [EPREFIX/lib]
   --includedir=DIRC header files [PREFIX/include]
   --oldincludedir=DIR C header files for non-gcc [/usr/include]
diff --git a/stubdom/configure b/stubdom/configure
index 8f0bdcf..e2443e9 100755
--- a/stubdom/configure
+++ b/stubdom/configure
@@ -661,7 +661,6 @@ infodir
 docdir
 oldincludedir
 includedir
-runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
@@ -751,7 +750,6 @@ datadir='${datarootdir}'
 sysconfdir='${prefix}/etc'
 sharedstatedir='${prefix}/com'