Adding required m4 files

[Peter Creath]

I am by no means an autom4te wizard, so I'm submitting this to the
list rather than commiting it to CVS.

Anyway, the attached tar allows your to compile straight out of CVS
(at least on Mac OS X) without having to install a bunch of extra
stuff.

I manually tweaked the attached autogen.sh to include files in the
attached "m4" directory, but there's probably a more elegant way to do
this.  Also, I don't know if we want to bother with distributing these
m4 files in the tarball, since they're only needed to run autoconf.

Incidentally, testpregap is currently failing the regression tests on
my machine.  Is this a known bug, or is it particular to my setup?

[Robert William Fuller]

Peter Creath wrote:

> I am by no means an autom4te wizard, so I'm submitting this to the
> list rather than commiting it to CVS.
>
> Anyway, the attached tar allows your to compile straight out of CVS
> (at least on Mac OS X) without having to install a bunch of extra
> stuff.
>
> I manually tweaked the attached autogen.sh to include files in the
> attached "m4" directory, but there's probably a more elegant way to do
> this.  Also, I don't know if we want to bother with distributing these
> m4 files in the tarball, since they're only needed to run autoconf.
>
> Incidentally, testpregap is currently failing the regression tests on
> my machine.  Is this a known bug, or is it particular to my setup?

Uhhh no it's not a known bug.  Not sure what to do about it....  I don't
have MacOS.

[Robert William Fuller]

Robert William Fuller wrote:
> Peter Creath wrote:

<snip>
>>
>> Anyway, the attached tar allows your to compile straight out of CVS
>> (at least on Mac OS X) without having to install a bunch of extra
>> stuff.

<snip>

>> Incidentally, testpregap is currently failing the regression tests on
>> my machine.  Is this a known bug, or is it particular to my setup?
>
> Uhhh no it's not a known bug.  Not sure what to do about it....  I don't
> have MacOS.

By the way, is it a PowerPC or an Intel box?  This should not be a
problem because I was careful to use the appropriate LE, BE (little
endian/big endian macros,) but I might have missed something.

[R. Bernstein]

Peter Creath writes:
 > I am by no means an autom4te wizard, so I'm submitting this to the
 > list rather than commiting it to CVS.
 >
 > Anyway, the attached tar allows your to compile straight out of CVS
 > (at least on Mac OS X) without having to install a bunch of extra
 > stuff.

The tar was too big for the GNU mailman default. I've since upped the
default to be able to handle an attachment of this size.

As best as I can tell the attachment didn't go through. But that's
okay, because I've just applied the patch along with some CVS adds so
it goes into the repository.

Do you know what specifically would have be be installed on Mac OS X?

 >
 > I manually tweaked the attached autogen.sh to include files in the
 > attached "m4" directory, but there's probably a more elegant way to do
 > this.  Also, I don't know if we want to bother with distributing these
 > m4 files in the tarball, since they're only needed to run autoconf.

The default behavior of the automate system seems to be to include
them. (More specifically, "make dist" includes the m4 directory
without any change above what you had.)a

 >
 > Incidentally, testpregap is currently failing the regression tests on
 > my machine.  Is this a known bug, or is it particular to my setup?

[Peter Creath]

On Sun, Jun 8, 2008 at 10:55 PM, R. Bernstein <rocky@...> wrote:
> Do you know what specifically would have be be installed on Mac OS X?

It looked like autogen.sh wanted gettext and pkg-config, neither of
which is really necessary to build libcdio.  It also couldn't find
iconv.m4, despite having iconv installed.

> The default behavior of the automate system seems to be to include
> them. (More specifically, "make dist" includes the m4 directory
> without any change above what you had.)

Once aclocal.m4 is created, you don't really need the m4 directory any
more.  So m4 probably shouldn't go into dist since autogen.sh doesn't
either.

[R. Bernstein]

Peter Creath writes:
 > On Sun, Jun 8, 2008 at 10:55 PM, R. Bernstein <rocky@...> wrote:
 > > Do you know what specifically would have be be installed on Mac OS X?
 >
 > It looked like autogen.sh wanted gettext and pkg-config, neither of
 > which is really necessary to build libcdio.  It also couldn't find
 > iconv.m4, despite having iconv installed.
 >
 > > The default behavior of the automate system seems to be to include
 > > them. (More specifically, "make dist" includes the m4 directory
 > > without any change above what you had.)
 >
 > Once aclocal.m4 is created, you don't really need the m4 directory any
 > more.  So m4 probably shouldn't go into dist since autogen.sh doesn't
 > either.

If you want to figure out how get auto* to exclude m4, by all means do so. I think there's some sort of EXCLUDE_... variable one can add.

[R. Bernstein]

Steven M. Schultz writes:
 >
 > On Mon, 9 Jun 2008, R. Bernstein wrote:
 >
 > > If you want to figure out how get auto* to exclude m4, by all means do so...
 >
 > My method would be to exclude the entire directory by requiring
 > properly configured systems if folks want to run ./autogen.sh :)  
 >
 > But what the heck, guess YET ONE MORE COPY of those m4 files on
 > the system won't matter ;)  

Again, if anyone is motivated enough to change the lingo in
Makefile.am, make the change or send a patch. Otherwise we live with
what we've got which is not harmful, just bloat.

[Peter Creath]

On Mon, Jun 9, 2008 at 1:33 PM, R. Bernstein <rocky@...> wrote:
> Again, if anyone is motivated enough to change the lingo in
> Makefile.am, make the change or send a patch. Otherwise we live with
> what we've got which is not harmful, just bloat.

I was going to tackle this, but now I'm puzzled:  the tarball for 0.80
had these m4 files in it at the top level (along with a config.rpath),
but CVS didn't.  How did that happen?

Running a "make distclean" out of CVS didn't produce them either.

[R. Bernstein]

Peter Creath writes:
 > On Mon, Jun 9, 2008 at 1:33 PM, R. Bernstein <rocky@...> wrote:
 > > Again, if anyone is motivated enough to change the lingo in
 > > Makefile.am, make the change or send a patch. Otherwise we live with
 > > what we've got which is not harmful, just bloat.
 >
 > I was going to tackle this, but now I'm puzzled:  the tarball for 0.80
 > had these m4 files in it at the top level (along with a config.rpath),
 > but CVS didn't.  How did that happen?

I removed them from CVS.  Your autogen.sh includes the m4 directory
(-I m4) so the duplicate m4 (at the top level) are no longer
needed. As for how to get CVS update to include the m4 directory, I
don't know the proper way. One thing that will work though is a new
checkout of the entire repository.

 >
 > Running a "make distclean" out of CVS didn't produce them either.

Not sure what it would.

[Peter Creath]

On Mon, Jun 9, 2008 at 1:33 PM, R. Bernstein <rocky@...> wrote:
> Steven M. Schultz writes:
>  > On Mon, 9 Jun 2008, R. Bernstein wrote:
>  > > If you want to figure out how get auto* to exclude m4, by all means do so...
>  >
>  >      My method would be to exclude the entire directory by requiring
>  >      properly configured systems if folks want to run ./autogen.sh :)
>  >
>  >      But what the heck, guess YET ONE MORE COPY of those m4 files on
>  >      the system won't matter ;)

Upon investigating this, it turns out that m4 lives in the tarball
because aclocal is including them rather than appending them to
aclocal.m4.  This is apparently the preferred behavior for automake.
Our new arrangement of placing required .m4 files in an m4 directory
we distribute is also discussed in
<http://www.gnu.org/software/libtool/manual/automake/Local-Macros.html>
(see the paragraph regarding "distribution of third-party macros").
So I think our change is a good one overall, especially since I
removed the superfluous libtool.m4.

While I was poking around automake, I also ran across this article
about the deprecation of aclocal and the recommendation to move from
autogen.sh to autoreconf:
<http://www.gnu.org/software/libtool/manual/automake/Future-of-aclocal.html>.

What do people think about replacing the guts of autogen.sh with a
call to autoreconf?  I can check in a patch if nobody sees a problem
with this.

Also, do we have any strong feelings about maintainer mode?  This
seems to be deprecated now as well:
<http://www.gnu.org/software/libtool/manual/automake/maintainer_002dmode.html>.
 It sounds like there are some reasons to still use it, but I don't
know if they apply to libcdio.  Rocky?

[R. Bernstein]

Peter Creath writes:
 > What do people think about replacing the guts of autogen.sh with a
 > call to autoreconf?  I can check in a patch if nobody sees a problem
 > with this.

Personally I'm not wedded to any of this crap. I sometimes use
autoreconf.

 >
 > Also, do we have any strong feelings about maintainer mode?  This
 > seems to be deprecated now as well:
 > <http://www.gnu.org/software/libtool/manual/automake/maintainer_002dmode.html>.
 >  It sounds like there are some reasons to still use it, but I don't
 > know if they apply to libcdio.  Rocky?

The URL cited above says:
   AM_MAINTAINER_MODE also allows you to disable some custom build rules conditionally.

Because it was there and getting turned on, I used it to add a rule
the regenreate the ChangeLog which I do just before a release. The
ChangeLog target assumes you have cvs2cl which I suspect many people
won't have.

As long as we keep some way to regenerate ChangeLog either as another
conditional or make it unconditional, I'm cool. Again, I'm not wedded
to this crap.

[Peter Creath]

On Tue, Jun 10, 2008 at 12:11 PM, R. Bernstein <rocky@...> wrote:
> Because it was there and getting turned on, I used it to add a rule
> the regenreate the ChangeLog which I do just before a release. The
> ChangeLog target assumes you have cvs2cl which I suspect many people
> won't have.
>
> As long as we keep some way to regenerate ChangeLog either as another
> conditional or make it unconditional, I'm cool. Again, I'm not wedded
> to this crap.

But ChangeLog only gets regenerated for make dist* targets, right?
Most people won't be doing that.

[R. Bernstein]

Peter Creath writes:
 > On Tue, Jun 10, 2008 at 12:11 PM, R. Bernstein <rocky@...> wrote:
 > > Because it was there and getting turned on, I used it to add a rule
 > > the regenreate the ChangeLog which I do just before a release. The
 > > ChangeLog target assumes you have cvs2cl which I suspect many people
 > > won't have.
 > >
 > > As long as we keep some way to regenerate ChangeLog either as another
 > > conditional or make it unconditional, I'm cool. Again, I'm not wedded
 > > to this crap.
 >
 > But ChangeLog only gets regenerated for make dist* targets, right?
Right.

 > Most people won't be doing that.

Right. The way things work right now is that target is commented out
unless --enable-maintainer-mode has been set. autogen.sh adds that
flag by default. Although one can get a log of changes directly from
CVS, people who check out from version control also have have a way to
create a ChangeLog via "make ChangeLog". And some of those people who
check out from CVS need to do make the ChangeLog for the release,
which is what the dist* targets automatically do.

[Peter Creath]

On Tue, Jun 10, 2008 at 12:11 PM, R. Bernstein <rocky@...> wrote:
> Peter Creath writes:
>  > What do people think about replacing the guts of autogen.sh with a
>  > call to autoreconf?  I can check in a patch if nobody sees a problem
>  > with this.
>
> Personally I'm not wedded to any of this crap. I sometimes use
> autoreconf.

I (finally) checked in a replacement autogen.sh that simply calls
autoreconf and configure.  It allows libcdio to build straight out of
CVS with no fuss, passing all regression tests.

Let me know if it causes anyone any problems.