Re: What's the name of this library? (was: Re: autotoolstransition report: v 28.07)

[Benjamin Kosnik <bkoz at redhat dot com>]

>The testcase code in question:
>
>    catalog cat_de = mssg_de.open("libstdc++", loc_c, dir);
>
>
>On Thu, Jul 31, 2003 at 08:56:21PM -0500, Benjamin Kosnik wrote:
>> old:
>> -rw-r--r--    1 bkoz     bkoz          490 Jul 31 20:24 libstdc++.mo
>> 
>> new:
>> -rw-r--r--    1 bkoz     bkoz          490 Jul 31 20:02 libstdc++-v3.mo
>
>
>> *** po.cvs/Makefile	2003-07-31 20:06:39.000000000 -0500
>> --- po.orig/Makefile	2003-07-31 18:19:26.000000000 -0500
>> ! PACKAGE = libstdc++
>> --- 65,208 ----
>> + PACKAGE = libstdc++-v3
>
>Your Honor, may I present Exhibit A: the smoking gun.

Thanks! 

>The 64-million-bit question:  do we call ourselves libstdc++, or libstdc++-v3?
>Ponder carefully; this affects more than what it used to.

Externally, I think it should be libstdc++, and internally I think some
parts have to be libstdc++-v3. The parts that are named libstdc++-v3
should be minimized, I think. If that involves renames in the testsuite,
well then, let's do it. I'm not particularly concerned about saving the
history there.

Sadly, I don't see anyway around this. Naming both libstdc++-v2 and
libstdc++-v3 with the same "libstdc++" name caused so many problems with
CVS that the dual-directory approach was the only way to go. During the
transition, I think this was a wise choice.

What does --enable-shared=libstdc++ do now? I guess I'm not quite sure
if the new AC/AM bits change this, and if so, how? 

Anyway. To fix this specific issue (with the message catalogs) easily
you could just do the following.

Just change this part of po/Makefile.am for the following rules:

check-yes:
install-data-local-yes: all-local-yes

from

	  $(INSTALL_DATA) $$cat $$install_dir/$(PACKAGE).mo; \

to

	  $(INSTALL_DATA) $$cat $$install_dir/libstdc++.mo; \

to fix this. This rule is pretty synthetic anyway.

-benjamin