Hello Dirk,
Monday, October 08, 2001, 7:45:39 PM, you wrote:
DM> On Mon, 08 Okt 2001, Eugene Kuznetsov wrote:
>> _Who_ does not ship missing and mkinstalldirs? Hint: they are not supposed
>> to be in CVS because they are automake-dependent and will be put there with call to
>autogen.sh.
DM> Not really. even the newest version of these two scripts work with the
DM> oldest setup I found.
Pure luck.
DM> consequently it shouldn't ship config.guess or config.sub either. these two
DM> cause frequently more trouble.
'Frequently'? I haven't heard about any such problems ... These files
are very unlikely to cause troubles because of their purpose. BTW they
are absent in CVS.
DM> consequently it should either not ship libtool at all, or ship a working
DM> libool version and use that one. the hardcoded libtoolize call in autogen.sh
DM> isn't the best way of doing things - imho avifile should come with one
DM> libtool that works. no need add libtool dependencies into the mess,
DM> especially as libtool is in cvs, but removed by automake everytime (screws
DM> up dependencies).
libtoolize is called anyway from automake ( both 1.4 and 1.5 ) when it sees that
some files ( ltconfig, mkinstalldirs, missing ) are missing. By placing this call
in front ot automake we get rid of one error message and force creation of missing
files.
Once again, there are no traces of libtool in CVS, system version of
libtool is used every time.
DM> consequently it shouldn't expose automake-version specific behaviour by
DM> putting configure.in and configure.ac there. all automake versions can read
DM> configure.in, not all can read configure.ac. why there is a symlink is
DM> beyond me.
Here I don't get the word 'consequently'. Why shouldn't we expose
automake-version specific behavior if different versions of automake
are not 100% compatible with each other?
DM> consequently it shouldn't put generated files in cvs and use hacks like
DM> touch to fix the dependencies again.
>> I've got autoconf 2.13 with automake 1.4 and it worked fine for me
>> ever since. Can't tell you about automake 1.5 for sure. As far as I
>> know they broke a lot of their compatibility with 1.4.
DM> Yes and no. Its for sure more strict and doesn't tolerate that many errors
DM> anymore.
It isn't 'more strict'. It just behaves differently from 1.4, making
it difficult to support both versions, and, luckily for us, adds
workarounds for some bugs.
Example 1: for automake 1.4 '.s' objects are valid sources that can be
put into 'xxxx_SOURCES' variable with no additional support from my side.
In 1.5 this does not work any more. Now I have to put AM_PROG_AS macro
in configure.ac. Of course, if I do that, I break compatibility with
1.4, because 1.4 does not know anything about AM_PROG_AS. The only way
out ( to support 1.4, 1.5 and whatever else gnu guys decide to do in
future ) is to write manual rules:
stubs.lo: stubs.s
$(CC) -c $(srcdir)/stubs.s -o stubs.lo
basically reverting to ancient style of writing makefiles.
Example 2: automake assumes that return value of 'cp' command-line
utility is somehow related to whether copy operation was successful or
not. It is ( as you say :) ) beyond me why they make this assumption,
because neither 'man cp' nor any other docs I have say that, and also
because it is not true - sometimes 'cp' returns !=0 even though it has
succeeded. This was the reason for a few bug reports during last couple
of weeks about 'error copying file'. This bug shows up with 1.4, but for
some reason not with 1.5.
In the end I must emphasize two things.
First: you don't see as many bug reports about automake stuff in other
projects because in most projects common users don't use automake and
compile pre-packaged sources with everything from mkinstalldirs to
configure included.
Second: in spite of all undocumented features gnu guys use in their
work and all incompatibilities they put in new versions ( obviously
the donation from Microsoft -
http://www.gnu.org/thankgnus/2000supporters.html - worked well ),
current CVS can be successfully built with automake 1.4 and 1.5
and autoconf 2.13 and 2.52.
--
Best regards,
Eugene mailto:[EMAIL PROTECTED]
_______________________________________________
Avifile mailing list
[EMAIL PROTECTED]
http://prak.org/mailman/listinfo/avifile
