Bug#386652: Incomplete job
On Feb 5, 2008 4:35 PM, Tuncer Ayaz [EMAIL PROTECTED] wrote: Just out of curiosity, would the following change break anything? --- configure.orig 2008-01-25 10:55:34.0 +0100 +++ configure 2008-01-25 10:56:14.0 +0100 @@ -4345,7 +4345,7 @@ test $svn_allowed_neon = any; then svn_allowed_neon_on_system=yes SVN_NEON_INCLUDES=`$neon_config --cflags | sed -e 's/-D[^ ]*//g'` -NEON_LIBS=`$neon_config --la-file` +NEON_LIBS=`$neon_config --libs` CFLAGS=$CFLAGS `$neon_config --cflags | sed -e 's/-I[^ ]*//g'` svn_lib_neon=yes break I'm asking because the version I built that way on Etch passes make check except some skipped tests which I did not skip manually. Shouldn't it be safe to apply this change to upstream subversion? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386652: Incomplete job
Just out of curiosity, would the following change break anything? --- configure.orig 2008-01-25 10:55:34.0 +0100 +++ configure 2008-01-25 10:56:14.0 +0100 @@ -4345,7 +4345,7 @@ test $svn_allowed_neon = any; then svn_allowed_neon_on_system=yes SVN_NEON_INCLUDES=`$neon_config --cflags | sed -e 's/-D[^ ]*//g'` -NEON_LIBS=`$neon_config --la-file` +NEON_LIBS=`$neon_config --libs` CFLAGS=$CFLAGS `$neon_config --cflags | sed -e 's/-I[^ ]*//g'` svn_lib_neon=yes break -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386652: Incomplete job
I don't know whether or not it's Correct to remove the .la file from the neon package (though I strongly suspect not). However, I'm pretty confident that when you removed the .la file from the package, you should have also caused 'neon-config --la-file' to stop claiming that callers could find the .la file for neon in a place it no longer resides. signature.asc Description: OpenPGP digital signature
Bug#386652: Incomplete job
[C. Michael Pilato] I'm pretty confident that when you removed the .la file from the package, you should have also caused 'neon-config --la-file' to stop claiming that callers could find the .la file for neon in a place it no longer resides. Yeah, well ... the --la-file option itself is a poor interface. The very existence of a .la file should be a libtool implementation detail that libraries and applications never need to know about. They should be asking what do I add to my link line to link to neon, not what is the filename for the internal libtool metadata for libneon. That said, since 'neon-config --la-file' is a preexisting interface, it should have been handled better. In practice the question it is answering is equivalent to what do I add to my link line, so it should answer accordingly, meaning it should give the same output as 'neon-config --libs'. As for the question of whether the .la file should have been deleted - I still think it should be deleted. libtool functions fine without a .la file, the need for this file was artificial created by neon-config having an option to expose the .la filename, which AFAICT applications never actually needed. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#386652: Incomplete job
[Peter Samuelson] Yeah, well ... the --la-file option itself is a poor interface. The very existence of a .la file should be a libtool implementation detail that libraries and applications never need to know about. They should be asking what do I add to my link line to link to neon, not what is the filename for the internal libtool metadata for libneon. Like I said, I don't know what's Correct. Clearly you've got opinions about how things would be in an ideal world. That said, since 'neon-config --la-file' is a preexisting interface, it should have been handled better. In practice the question it is answering is equivalent to what do I add to my link line, so it should answer accordingly, meaning it should give the same output as 'neon-config --libs'. Or, why not simply ship the .la file as libneon26.la, and have neon-config refer to that? There's absolutely no reason that I can think of why this can't all be done in a way that allows multiple versions of neon to coexist. As for the question of whether the .la file should have been deleted - I still think it should be deleted. libtool functions fine without a .la file, the need for this file was artificial created by neon-config having an option to expose the .la filename, which AFAICT applications never actually needed. Unfortunately, this seems to break the build of the very software you originally wished to make this change for -- Subversion. Subversion uses 'neon-config --la-file' to find neon. signature.asc Description: OpenPGP digital signature
