Re: [Opencxx-users] rel_2_8 branch

[Grzegorz J. <ja...@ac...>]

Gilles J. Seguin wrote:
> On Fri, 2004-07-09 at 06:30, Grzegorz Jakacki wrote:
> 
>>Hi Gilles!
>>
>>Thank you very much for your feedback.
>>
>>This is not clear to me,
> 
> 
> OK, it is not clear.
> Patches can be applied even if others behavior are not
> what I would like to be.  

Ok, I see.

 > But must not break the GC.
> 
> 
>>however, if the make output you gave is *before*
>>or *after* the patches have been applied.
> 
> 
> Patches are relative to branch rel_2_8.
> The ability to do 'make' in the build directory was lost.

I see.

> This is a nice option to test little patch or to keep
> multiple binary version.

Sure.

> $ cd /home1/opencxx
> $ ./bootstrap
> $ cd ..
> $ mkdir build
> $ cd build
> $ ../opencxx/configure --prefix=/usr --srcdir=../opencxx \
>  --datadir=/usr/share --disable-gc
> $ make
> was failing because option -I../opencxx is required in that
> situation.

I see.

>>Can you build now with your patches? 
> 
> 
> $ make
> succeed
> $ make unittests
> $ make check
> IIRC, also succeed. they are the same make target.

Right.

> $ make test
> 
>>Do gc tests pass?
> 
> not tested
> 
> 
>>If not, then could you send the 
>>complete output of bootstrap+configure+make ?
>>
>>Thanks again
>>Grzegorz
>>
>>
>>Gilles J. Seguin wrote:
>>
>>>On Wed, 2004-07-07 at 09:49, Grzegorz Jakacki wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>HEAD passed the following tests on CF:
>>>>
>>>>* powerpc-apple-darwin6.8/nogc/gcc-3.3
>>>>* i686-pc-linux-gnu/gc-6.2/gcc-2.95.2 (Debian)
>>>>
>>>>I am still waiting for RedHat host on Compile Farm to go up to
>>>>test on RedHat.
>>>>
>>>>I created a branch rel_2_8 and it eventually will be released
>>>>as 2.8;this is a beta release, with major restructurings
>>>>applied to the code. 
>>>
>>>On Fedora Core 2
>>>with rel_2_8
>>>make from a build directory fail.
>>>I have applied following patches
>>>
>>>make test
> 
> [...]
> 
>>>/bin/sh ../../opencxx/mkinstalldirs /usr/share/opencxx/html
>>>mkdir -p -- /usr/share/opencxx/html
>>>mkdir: cannot create directory
>>>`/usr/share/opencxx': Permission denied
>>>
>>>something is very wrong, here
> 
> 
> More extensively, my believe is that
> - we can install the opencxx build required libraries under the
>   testsuite subdirectory.

The intention was to install them in ${builddir}/testbed . If it does 
not happen, this is a bug.

> - it can be done without root privilege.

Yes, this was also my intention.

> - it can be done without reconfiguring.

Unfortunately, I don't think it can be easily avoided.

The libtool libraries (*.la files) should be "installed" before they are 
linked against. On some systems you cannot link against shared library 
unless it is installed in one specific directory, which is hardcoded in 
the shared library file.

This means, that when the *.la file is created the path at which it is 
going to be installed must be known.

In case of OpenC++ libtool is called from Makefile, and this Makefile is 
generated from Makefile.am by Automake and configure. Automake creates 
all the logic and configure only fills-in parameters like @builddir@, 
@libdir@ etc. This logic calls libtool in such a way, that the library 
installation path is $libdir, and I don't know about any easy way to 
force Automake to supply another installation path when calling libtool.

This means that in order to be able to run tests that do dynamic 
linking, we need to install shared libraries. I don't want to force 
users to install in /usr/lib or in system-wide location before they can 
test, so I came up with an idea, that for testing they will be 
provisionally installed in ${builddir}/testbed . As outlined above, due 
to Automake limitations it is difficult to do it without 
reconfiguration. So when you say 'make test' and $prefix is not 
`pwd`/testbed , the sources are reconfigured with --prefix=`pwd`/testbed
(and --enable-libltdl-install, more about it in a moment).

> What is missing,
> - the advance understanding of the aclocal, automake, libtool,
>   and autoconf tools.
> - And answers to other occult behaviors.
>   Why is the libltdl being built, don't we have specify
>   AC_LIBLTDL_INSTALLABLE, AC_LIB_LTDL
>   and I have obviously the libtools package.

I had a lots of problems with old libltdl installed on a system (this 
especially showed up on Compile Farm, where I cannot just upgrade it). 
Thus when OpenC++ is reconfigured for testing it forces building the 
bundled libltdl, no matter if libltdl is available system-wide.

> - the patches.

I applied patches from your previous e-mail. I will try to have a look 
builddir!=srcdir before 2.8 release. If you find any further facts that 
would help, please let me know.

Thanks!
Grzegorz