[Fedora-directory-devel] Please review: [Bug 212098] Use autoconf to generate task perl script templates

[Noriko Hosoi]

Summary: Use autoconf to generate task perl script templates

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212098

Problem Description:
Notes in Comment#1
2. The template files are not "installed" now.

With this change, the perl template files are installed in $prefix/etc/brand-ds/script-templates

------- Additional Comments From [e-mail]  2006-10-25 18:34 EST -------
Created an attachment (id=139419)
 --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139419&action=vie...)
cvs diff configure.ac Makefile.am

Files:
  configure.ac
  MAkefile.am

Changes;
1) added task perl script templates to "install" at
@sysconfdir@@scripttemplatedir@ to Makefile.am
2) added scripttemplatedir = /fedora-ds/script-templates to configure.ac

Question: changing these files, Makefile.in and configure are also updated.  Am
I supposed to check them in?
M Makefile.am
M Makefile.in
M configure
M configure.ac

What    |Removed                     |Added
----------------------------------------------------------------------------
   devel_whiteboard|                            |review.comment#7?

[Andrew Bartlett]

On Wed, 2006-10-25 at 15:43 -0700, Noriko Hosoi wrote:
> Summary: Use autoconf to generate task perl script templates
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212098
>
> Problem Description:
> Notes in Comment#1
> 2. The template files are not "installed" now.
>
> With this change, the perl template files are installed in $prefix/etc/brand-ds/script-templates
>
> ------- Additional Comments From [e-mail]  2006-10-25 18:34 EST -------
> Created an attachment (id=139419)
>  --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139419&action=vie...)
> cvs diff configure.ac Makefile.am
>
> Files:
>   configure.ac
>   MAkefile.am
>
> Changes;
> added task perl script templates to "install" at
>
> @sysconfdir@@scripttemplatedir@ to Makefile.am
> 2) added scripttemplatedir = /fedora-ds/script-templates to configure.ac
>
> Question: changing these files, Makefile.in and configure are also updated.  Am
> I supposed to check them in?
> M Makefile.am
> M Makefile.in
> M configure
> M configure.ac

This depends on the project, and I don't know the rules here.

In Samba (just as a note, for comparison), we did commit these generated
files our to CVS for many years, but it just created a lot of noise on
commit, as different developers had slightly different tools, which
would rearrange the files rather often.

Our current policy is to generate these files for release tarballs, and
for our 'unpacked' tree on samba.org (current SVN checked out).

Andrew Bartlett

[Pete Rowley]

Andrew Bartlett wrote:
> On Wed, 2006-10-25 at 15:43 -0700, Noriko Hosoi wrote:
> > Summary: Use autoconf to generate task perl script templates
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212098
> >
> > Problem Description:
> > Notes in Comment#1
> > 2. The template files are not "installed" now.
> >
> > With this change, the perl template files are installed in $prefix/etc/brand-ds/script-templates
> >
> > ------- Additional Comments From [e-mail]  2006-10-25 18:34 EST -------
> > Created an attachment (id=139419)
> >  --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139419&action=vie...)
> > cvs diff configure.ac Makefile.am
> >
> > Files:
> >   configure.ac
> >   MAkefile.am
> >
> > Changes;
> > added task perl script templates to "install" at
> >
> > @sysconfdir@@scripttemplatedir@ to Makefile.am
> > 2) added scripttemplatedir = /fedora-ds/script-templates to configure.ac
> >
> > Question: changing these files, Makefile.in and configure are also updated.  Am
> > I supposed to check them in?
> > M Makefile.am
> > M Makefile.in
> > M configure
> > M configure.ac
>
> This depends on the project, and I don't know the rules here.
>
> In Samba (just as a note, for comparison), we did commit these generated
> files our to CVS for many years, but it just created a lot of noise on
> commit, as different developers had slightly different tools, which
> would rearrange the files rather often.
>
> Our current policy is to generate these files for release tarballs, and
> for our 'unpacked' tree on samba.org (current SVN checked out).

OTOH they are required in order to do:

cvs co
./configure
make

[Noriko Hosoi]

Thank you for your comments, Andrew and Pete!

Nathan told me that we should check them in since we should not expect 
customers to run autoconf/automake.  But we are skipping to put the 
diffs to the review request.  I think the rule looks similar to the 
samba rule and am going to follow it...

Thanks!
--noriko

Pete Rowley wrote:
> Andrew Bartlett wrote:
> > On Wed, 2006-10-25 at 15:43 -0700, Noriko Hosoi wrote:
> > > Summary: Use autoconf to generate task perl script templates
> > >
> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212098
> > >
> > > Problem Description:
> > > Notes in Comment#1
> > > 2. The template files are not "installed" now.
> > >
> > > With this change, the perl template files are installed in 
> > > $prefix/etc/brand-ds/script-templates
> > >
> > > ------- Additional Comments From [e-mail]  2006-10-25 
> > > 18:34 EST -------
> > > Created an attachment (id=139419)
> > >  --> 
> > > (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139419&action=vie...)
> > >
> > > cvs diff configure.ac Makefile.am
> > >
> > > Files:
> > >   configure.ac
> > >   MAkefile.am
> > >
> > > Changes;
> > > added task perl script templates to "install" at
> > >
> > > @sysconfdir@@scripttemplatedir@ to Makefile.am
> > > 2) added scripttemplatedir = /fedora-ds/script-templates to 
> > > configure.ac
> > >
> > > Question: changing these files, Makefile.in and configure are also 
> > > updated.  Am
> > > I supposed to check them in?
> > > M Makefile.am
> > > M Makefile.in
> > > M configure
> > > M configure.ac
> >
> > This depends on the project, and I don't know the rules here. 
> > In Samba (just as a note, for comparison), we did commit these generated
> > files our to CVS for many years, but it just created a lot of noise on
> > commit, as different developers had slightly different tools, which
> > would rearrange the files rather often.
> >
> > Our current policy is to generate these files for release tarballs, and
> > for our 'unpacked' tree on samba.org (current SVN checked out).
>
> OTOH they are required in order to do:
>
> cvs co
> ./configure
> make
>
> --
> Fedora-directory-devel mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-devel

[Andrew Bartlett]

On Wed, 2006-10-25 at 18:14 -0700, Pete Rowley wrote:
> Andrew Bartlett wrote:
> > Our current policy is to generate these files for release tarballs, and
> > for our 'unpacked' tree on samba.org (current SVN checked out).
>
> OTOH they are required in order to do:
>
> cvs co
> ./configure
> make

Yeah, projects typically end up with an ./autogen.sh to make the right
innovation of the configure generation tool.

Andrew Bartlett

[Rich Megginson]

Andrew Bartlett wrote:
> On Wed, 2006-10-25 at 18:14 -0700, Pete Rowley wrote:
> > Andrew Bartlett wrote:
> > > Our current policy is to generate these files for release tarballs, and
> > > for our 'unpacked' tree on samba.org (current SVN checked out).
> >
> > OTOH they are required in order to do:
> >
> > cvs co
> > ./configure
> > make
>
> Yeah, projects typically end up with an ./autogen.sh to make the right
> innovation of the configure generation tool.

I've found that using autoreconf usually does the right thing.  When I 
change configure.ac/in or Makefile.am or an .m4 file, I always run
autoreconf -vfi
  -v, --verbose            verbosely report processing
  -f, --force              consider all files obsolete
  -i, --install            copy missing auxiliary files
It takes a little longer, but I almost never have conflict or timestamp 
problems.  Plus, it's part of the standard autotools package, and it is 
the way the autoconf/automake manuals recommend rebuilding the autotool 
files.
For some projects, this won't work (e.g. for mozldap, you have to just 
use autoconf-2.13, not autoreconf or autoreconf-2.13).
> Andrew Bartlett
>
> --
> Fedora-directory-devel mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-devel

[Nathan Kinder]

Richard Megginson wrote:
> Andrew Bartlett wrote:
> > On Wed, 2006-10-25 at 18:14 -0700, Pete Rowley wrote:
> > > Andrew Bartlett wrote:
> > > > Our current policy is to generate these files for release tarballs, 
> > > > and
> > > > for our 'unpacked' tree on samba.org (current SVN checked out).
> > >
> > > OTOH they are required in order to do:
> > >
> > > cvs co
> > > ./configure
> > > make
> >
> > Yeah, projects typically end up with an ./autogen.sh to make the right
> > innovation of the configure generation tool.
>
> I've found that using autoreconf usually does the right thing.  When I 
> change configure.ac/in or Makefile.am or an .m4 file, I always run
> autoreconf -vfi
>  -v, --verbose            verbosely report processing
>  -f, --force              consider all files obsolete
>  -i, --install            copy missing auxiliary files
> It takes a little longer, but I almost never have conflict or 
> timestamp problems.  Plus, it's part of the standard autotools 
> package, and it is the way the autoconf/automake manuals recommend 
> rebuilding the autotool files.
> For some projects, this won't work (e.g. for mozldap, you have to just 
> use autoconf-2.13, not autoreconf or autoreconf-2.13).

As I just very recently found out, we also need a very specific version 
of libtool (1.5.22) to generate ltmain.sh if we want to be able to build 
a 64-bit Directory Server on Solaris.  Running "autoreconf -fvi" will 
generate a new ltmain.sh that may be a version that we don't want to 
check in if we expect to be able to immediately run "configure; make 
install" after checking out the code.

-NGK
> > Andrew Bartlett
> >
> > -- 
> > Fedora-directory-devel mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>
> --
> Fedora-directory-devel mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-devel

[Rob Crittenden]

Nathan Kinder wrote:
> Richard Megginson wrote:
> > Andrew Bartlett wrote:
> > > On Wed, 2006-10-25 at 18:14 -0700, Pete Rowley wrote:
> > > > Andrew Bartlett wrote:
> > > > > Our current policy is to generate these files for release tarballs, 
> > > > > and
> > > > > for our 'unpacked' tree on samba.org (current SVN checked out).
> > > >
> > > > OTOH they are required in order to do:
> > > >
> > > > cvs co
> > > > ./configure
> > > > make
> > >
> > > Yeah, projects typically end up with an ./autogen.sh to make the right
> > > innovation of the configure generation tool.
> >
> > I've found that using autoreconf usually does the right thing.  When I 
> > change configure.ac/in or Makefile.am or an .m4 file, I always run
> > autoreconf -vfi
> >  -v, --verbose            verbosely report processing
> >  -f, --force              consider all files obsolete
> >  -i, --install            copy missing auxiliary files
> > It takes a little longer, but I almost never have conflict or 
> > timestamp problems.  Plus, it's part of the standard autotools 
> > package, and it is the way the autoconf/automake manuals recommend 
> > rebuilding the autotool files.
> > For some projects, this won't work (e.g. for mozldap, you have to just 
> > use autoconf-2.13, not autoreconf or autoreconf-2.13).
>
> As I just very recently found out, we also need a very specific version 
> of libtool (1.5.22) to generate ltmain.sh if we want to be able to build 
> a 64-bit Directory Server on Solaris.  Running "autoreconf -fvi" will 
> generate a new ltmain.sh that may be a version that we don't want to 
> check in if we expect to be able to immediately run "configure; make 
> install" after checking out the code.
>
> -NGK

The real pain is when not all of the files have changed and you check in 
only those that did. This can cause an unwanted auto* rebuild.

I've taken to checking everything in at once whenever one thing changes 
with:

cvs ci -f Makefile.am configure.in aclocal.m4 Makefile.in configure

This preserves the proper timestamp/dependency order (at least for me).

rob

[Rich Megginson]

Rob Crittenden wrote:
> Nathan Kinder wrote:
> > Richard Megginson wrote:
> > > Andrew Bartlett wrote:
> > > > On Wed, 2006-10-25 at 18:14 -0700, Pete Rowley wrote:
> > > > > Andrew Bartlett wrote:
> > > > > > Our current policy is to generate these files for release 
> > > > > > tarballs, and
> > > > > > for our 'unpacked' tree on samba.org (current SVN checked out).
> > > > >
> > > > > OTOH they are required in order to do:
> > > > >
> > > > > cvs co
> > > > > ./configure
> > > > > make
> > > >
> > > > Yeah, projects typically end up with an ./autogen.sh to make the right
> > > > innovation of the configure generation tool.
> > >
> > > I've found that using autoreconf usually does the right thing.  When 
> > > I change configure.ac/in or Makefile.am or an .m4 file, I always run
> > > autoreconf -vfi
> > >  -v, --verbose            verbosely report processing
> > >  -f, --force              consider all files obsolete
> > >  -i, --install            copy missing auxiliary files
> > > It takes a little longer, but I almost never have conflict or 
> > > timestamp problems.  Plus, it's part of the standard autotools 
> > > package, and it is the way the autoconf/automake manuals recommend 
> > > rebuilding the autotool files.
> > > For some projects, this won't work (e.g. for mozldap, you have to 
> > > just use autoconf-2.13, not autoreconf or autoreconf-2.13).
> >
> > As I just very recently found out, we also need a very specific 
> > version of libtool (1.5.22) to generate ltmain.sh if we want to be 
> > able to build a 64-bit Directory Server on Solaris.  Running 
> > "autoreconf -fvi" will generate a new ltmain.sh that may be a version 
> > that we don't want to check in if we expect to be able to immediately 
> > run "configure; make install" after checking out the code.
> >
> > -NGK
>
> The real pain is when not all of the files have changed and you check 
> in only those that did. This can cause an unwanted auto* rebuild.
>
> I've taken to checking everything in at once whenever one thing 
> changes with:
>
> cvs ci -f Makefile.am configure.in aclocal.m4 Makefile.in configure
>
> This preserves the proper timestamp/dependency order (at least for me).

If autoreconf doesn't work for directory server, do we need to create an 
autogen.sh script that "does the right thing"?  I would rather not, but 
if that is the only way to preserve the correct version of ltmain.sh, 
then we need to do it.  For example, we won't be able to use libtool on 
RHEL4 (with the standard RH updates anyway) because the bundled version 
of libtool is 1.5.6.  However, Fedora Core 5 (and probably RHEL5) are ok 
because they use 1.5.22.  I fear this may not be the only problem with 
autotool compatability - we also had a problem with hpux 11.23 ia64.

So, some options:
1) Only use autoreconf, and only run it on systems that use recent 
versions of autotools (e.g. fc5) - do not allow the use of autotools on 
RHEL4 or other less recent platforms.
2) Create an autogen.sh that first looks at the versions of the tools on 
the system and bails out if it finds an incompatible version - note that 
we would still have to run it on a modern system in order to actually 
update the autoconf files
2a) Have autogen.sh "patch" ltmain.sh when run on less recent systems, 
to allow us to use it on RHEL4 etc.
3) Make ltmain.sh (and possibly other files) somehow read-only with 
respect to autoreconf
> rob
>
> --
> Fedora-directory-devel mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-directory-devel