need new external module cppunit

@lla:  Please consider doing this in a clean way.  That is, instead of
extracting modified bits of CppUnit plus additions to CppUnit from module
testshl2 to new module cppunit, do the following:
- host an unmodified CppUnit in new module cppunit;
- (trivially) adapt those tests that do not need the additional features of
testshl2 to work against plain CppUnit instead of testshl2 (it is expected that
this covers all tests in udk modules, see
<http://www.openoffice.org/issues/show_bug.cgi?id=86525#desc10>);
- change module testshl2 to work on top of module cppunit deliverables;
- keep those tests running against testshl2 that do need the additional features
of testshl2.

As a proof of concept I attach cppunit.diff that does two things (relative to
DEV300m0):
- Introduce CppUnit 1.12.1 (currently latest version) as external module cppunit
into the built system; the proof of concept just makes sure it works with
setsolar-environment unxsoli4.pro, it is understood that some work will be
necessary to make it work well with all platforms and with the
configure-environment, and to potentially skip it in favor of a CppUnit already
available on the system.
- Change tests in sal/qa/sal to directly use CppUnit instead of testshl2 (and
execute those tests during the build).

Created attachment 51813 [details]
proof of concept

reopen as stephan suggested.

set target and mark as blocker for 3.0 release.

started

fixed.
At the moment the testshl2 code contains the 'patched' cppunit code which is in
the external project. To build testshl2 you need to get the external code,
create it, deliver it, than build the testshl2 code.

The next will be to support the last cppunit code, forward to #i91343#

This task is mine.

verified.

Where is the issue for the new cvs alias?

@cloph:
Sorry, but I don't understand what do you mean with ''new cvs alias''.
Could you be a little bit more specific, please.

building of the cws fails with: 
Fetching dependencies for module cppunit from solver... failed...

so the build now requires a module named cppunit. But that module cannot be
checked out:  
cvs co cppunit
cvs server: cannot find module `cppunit' - ignored
cvs [checkout aborted]: cannot expand modules

(not to mention that it obviously is not included in the OpenOffice2 or
OpenOffice3 aliases either)

@cloph:
Read this:

http://external.openoffice.org/source/browse/external/

how to get cvs access to the external project and how to check out. In the
external project you will find the cppunit module.

@lla: please read
http://wiki.services.openoffice.org/wiki/CWS#Create_a_new_module about what to
do for new modules. Amongst other things: get an CVS alias.

I've no idea at all how this can be called fixed.

cppunit contains a (unused!) cppunit tarball and code is still built from
cppunit/souce.

reopening.

please do it like sbs comment (cppunit + patch as any other external module)

reset target. (was a release stopper for 3.0, so targetting 3.0.1)

change owner.

you're kidding in making this a release blocker for 3.0.1, 3 days before code
freeze. Resetting target to 3.1.

The general problem - cppunit should be extracted from the source tarball,
patched and built, instead of building a committed modified source, is
understood and accepted. However, IMO this is nothing we should burn resources
for in the current phase of the release.

removing "blocking" status for issue 93339, since IMO this cannot be a blocker
for the 3.1 release, in the current phase of the release.

fs: ah, and that's why you burn stuff on 3.1 which is far away instead? no,
sorry. (but I won't reset the target, I am completely aware that Sun doesn't
care about legal issues, and that you didn't even check whether the fix which
claimed to fix this issue was correct).

No, I was not kidding, that cws could be done by the respective person in less
than 1 day.

fs->rene: Let's please stick to facts: 

> and that you didn't even check whether the fix which claimed to fix this issue
> was correct).

I already said that the bug as such is accepted to be a bug, which implies the
claimed fix is not a fix. That's not the point here.

> I am completely aware that Sun doesn't care about legal issues

Discussing on this level won't help us here.

That's the first time that legal issues are mentioned in this issue. I was/am
not aware that the current situation *is* a legal problem, so sorry for my
ignorance. All I can read here did not give me an idea about this.

So, you or somebody else please *argue* why this should be a 3.0.1, instead of
throwing around ridiculous (sorry) accusations.

Until then, I won't accept members of my team being put under pressure with an
issue whose importance is simply not clear to me from the re/sources I have. If
it is, then I will.

update:
Module cppunit is part of the "external" project. As a consequence, it should
not be part of the "normal" source tarball, but of the one provided for external
source code. (Still need to check this.)
If and only if this is correct, we do *not* have a legal problem.

For 3.1 (where the notion of external modules seems to have vanished, since in
SVN, there's no projects/modules anymore, but just top-level directories), we
*might* have a problem. But in this case, the 3.1 target here would be appropriate.

Rene?

fs: good joke.

a) most of the external libs are not in the tarball for external libs (-system).
   Yes, this is bogus.
b) I don't find the issue anymore but the  legal problems were raised by mmeeks in
   the ESC. Will try to find a source...

fs:

16:22 <@mmeeks> _rene_: saw that come across the mail box ;-)
16:22 <@mmeeks> _rene_: I don't recall if there was an issue - but the bug was 
                that they had a load of LGPL code in there without any license, 
                or copyright information,.
16:22 <@mmeeks> _rene_: intermingled with their change

and this is still the case in DEV300s cppunit.

s/DEV300/OOO300s and DEV300s/

>b) I don't find the issue anymore but the  legal problems were raised by mmeeks in 
> the ESC. Will try to find a source...

Last I looked the legal problem consisted of taking a load of LGPL code, and
including it in OO.o svn, outside the 'external' project - but *particularly*
not including the relevant license and copyright notices that went with it.
Clearly just moving this to the 'external' project [ while fixing OO.o policy ]
does nothing to help the license angle.

fs: convinced?

Convinced

Okay, just to see if we have a common ground.
We need to
- fix the cppunit module so that it does *not* contain modified copies of the
  cppunit code, but instead uses the usual mechanism for external source code:
  A source tarball in <module>/download, plus a patch file applied on top of
  that.
- move cppunit's source to the external libs tarball (-system)

This has to happen on both OOO300 and DEV300, of course.

Correct?

> Last I looked the legal problem consisted of taking a load of LGPL code, and
> including it in OO.o svn, outside the 'external' project - but *particularly*
> not including the relevant license and copyright notices that went with it.
> Clearly just moving this to the 'external' project [ while fixing OO.o
> policy ] does nothing to help the license angle.

Michael, I'm not sure what you suggest what needs to be done here. Could you
please elaborate?

fs: yes

and I'd add:
 - add --with-system-cppunit if possible (but that can be done later)

now that we have a consensus, readding as blocker.

> and I'd add:
>  - add --with-system-cppunit if possible (but that can be done later)

Okay, but I really would like to separate this out, as is the move to a more
recent cppunit version. At the moment, I'd really like to concentrate on getting
the necessary things in for 3.0.1.
Does there already exist an issue requesting this configure switch?

(How did you manage to add 86509 as blocks/depends-on issue? This is a trivial
circular dependency which IZ normally rejects.)

lla: 1.8.0?! from what museum is this? ;-)

Debian etch (~2 years old) has 1.12. Looking at archive.debian.org shows
that sarge even had 1.10, makes 1.8 being the woody version....

All foreign sources removed.
Patch created.
Fixed.

> Okay, but I really would like to separate this out, as is the move to a more
> recent cppunit version. At the moment, I'd really like to concentrate on getting
> the necessary things in for 3.0.1.

yep, understandable. I just wanted to point out the ancientness of what we have
here :-)

> Does there already exist an issue requesting this configure switch?

Yes, this one ;-) (sbs comment). And a update to 1.12 might be a prereq for this
in any case, so...

Ok, the cppunit-1.8.0 if from far before
http://en.wikipedia.org/wiki/Russian_campaign ;-) but it works as expected. The
project testshl2 needs this cppunit version.

->rene: There exist i91343 to do such update. It is planned to use a less
patched cppunit-1.12 version. Which has no dependencies on other projects like sal.

> > Does there already exist an issue requesting this configure switch?
> Yes, this one ;-) (sbs comment). And a update to 1.12 might be a prereq for
> this in any case, so...

Uhm, no, I was talking about an issue for --with-system-cppunit, and this is not
what Stephan's comment is about.

I think we all know that 1.8.0 is stone aged, but we're one day before code
freeze, and we want to solve a legal issue, so let's do this right now, and move
all other nice-to-have things into other issues.

As Lars mentioned, issue 91343 is for moving to a recent cppunit version. This
move certainly is a pre-requisite for --with-system-cppunit, for which no issue
exists so far (so I understood).

in my understanding, the immediate problem is fixed in CWS qadev34t: Now the
usual "extract/patch/build" mechanism for external sources is used. As mentioned
above, moving to a recent version of cppunit, shrinking the (currently huge)
patch to the necessary parts, and adjusting unit tests to use cppunit instead of
testshl - all those are future tasks, and not covered by this issue here.

fs: I've no idea how you QAed it, but  a build fails miserably:

http://zyklop.dyndns.org/~rene/cppunit-cws-build.log
(cppunit updated with cvs up -dP -r cws_ooo300_qadev34t)

fs->rene: I checked the build works - unfortunately it seems I used a CWS copy
with uncommitted files :-\ Since Tinderbox builds were not available, I assumed
the build to be okay. Sorry. Lars will commit the missing changes in solenv.

->rene: Sorry, my fault, please take update your solenv/inc/tg_ext.mk and try again.

lla: ... just that cvs up -dP -r cws_ooo300_qadev34t in solenv removes all of
solenv-...

ok, I used anoncvs and it was behind the tag/commit...

... but now it fails inside the cppunit build...

Making: ../../../../../../unxlngppc.pro/slo/SynchronizedObject.obj
g++ -fsigned-char -fmessage-length=0 -c -Os -fno-strict-aliasing   -I. 
-I../../../../../../unxlngppc.pro/inc/c5t_testresult -I../inc
-I../../include/inc -I../../../../../../inc/pch -I../../../../../../inc
-I../../../../../../unx/inc -I../../../../../../unxlngppc.pro/inc -I.
-I/home/rene/OpenOffice.org/OOO300_m9/solver/300/unxlngppc.pro/inc/stl
-I/home/rene/OpenOffice.org/OOO300_m9/solver/300/unxlngppc.pro/inc/external
-I/home/rene/OpenOffice.org/OOO300_m9/solver/300/unxlngppc.pro/inc
-I/home/rene/OpenOffice.org/OOO300_m9/solenv/unxlngppc/inc
-I/home/rene/OpenOffice.org/OOO300_m9/solenv/inc
-I/home/rene/OpenOffice.org/OOO300_m9/res
-I/home/rene/OpenOffice.org/OOO300_m9/solver/300/unxlngppc.pro/inc/stl
-I/home/rene/OpenOffice.org/OOO300_m9/solenv/inc/Xp31 -INO_JAVA_HOME/include
-INO_JAVA_HOME/include/linux -INO_JAVA_HOME/include/native_threads/include
-I/usr/include 
-I/home/rene/OpenOffice.org/OOO300_m9/solver/300/unxlngppc.pro/inc/offuh -I.
-I../../../../../../res -I. -fsigned-char -pipe -frtti   -Wno-ctor-dtor-privacy
  -fPIC -DLINUX -DUNX -DVCL -DGCC -DC300 -DPOWERPC -DCVER=C300 -DNPTL -DGLIBC=2
-D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400
-DPOWERPC -DPPC -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3
-DGXX_INCLUDE_PATH=/usr/include/c++/4.3 -DSUPD=300 -DPRODUCT -DNDEBUG
-DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI   -DSHAREDLIB -D_DLL_  
-fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON  -o
../../../../../../unxlngppc.pro/slo/SynchronizedObject.o
/home/rene/OpenOffice.org/OOO300_m9/cppunit/unxlngppc.pro/misc/build/cppunit-1.8.0/src/result/SynchronizedObject.cpp
/home/rene/OpenOffice.org/OOO300_m9/cppunit/unxlngppc.pro/misc/build/cppunit-1.8.0/src/result/SynchronizedObject.cpp:1:47:
error: cppunit/result/SynchronizedObject.h: No such file or directory
/home/rene/OpenOffice.org/OOO300_m9/cppunit/unxlngppc.pro/misc/build/cppunit-1.8.0/src/result/SynchronizedObject.cpp:10:
error: 'SynchronizedObject' has not been declared
/home/rene/OpenOffice.org/OOO300_m9/cppunit/unxlngppc.pro/misc/build/cppunit-1.8.0/src/result/SynchronizedObject.cpp:10:
error: expected constructor, destructor, or type conversion before '(' token
/home/rene/OpenOffice.org/OOO300_m9/cppunit/unxlngppc.pro/misc/build/cppunit-1.8.0/src/result/SynchronizedObject.cpp:17:
error: expected constructor, destructor, or type conversion before '::' token
/home/rene/OpenOffice.org/OOO300_m9/cppunit/unxlngppc.pro/misc/build/cppunit-1.8.0/src/result/SynchronizedObject.cpp:27:
error: 'SynchronizedObject' has not been declared
/home/rene/OpenOffice.org/OOO300_m9/cppunit/unxlngppc.pro/misc/build/cppunit-1.8.0/src/result/SynchronizedObject.cpp:27:
error: variable or field 'setSynchronizationObject' declared void
/home/rene/OpenOffice.org/OOO300_m9/cppunit/unxlngppc.pro/misc/build/cppunit-1.8.0/src/result/SynchronizedObject.cpp:27:
error: 'SynchronizationObject' was not declared in this scope
/home/rene/OpenOffice.org/OOO300_m9/cppunit/unxlngppc.pro/misc/build/cppunit-1.8.0/src/result/SynchronizedObject.cpp:27:
error: 'syncObject' was not declared in this scope
dmake:  Error code 1, while making
'../../../../../../unxlngppc.pro/slo/SynchronizedObject.obj'
dmake:  Error code 255, while making 'target'
dmake:  Error code 255, while making
'./unxlngppc.pro/misc/build/so_built_so_cppunit'

ERROR: Error 65280 occurred while making /home/rene/OpenOffice.org/OOO300_m9/cppunit
rmdir /tmp/26489

FWIW, the quickest way to solve the legal issue is to add the README and COPYING
files and whatever other copyright notices there are into the source directory.
Since that has zero impact on build-ability, the object files, or whatever:
presumably it could be done quickly ;-)

I'd personally recommend that approach; then make it perfect going forward post
release etc. [ new cppunit, better unit tests etc. ;-]

->rene: the next try.
My next fault. The problem was our build environment. It holds the old include
files in an extra directory where I not delete some files for tests. Also the
PRJINC= variable in the makefile.mk files was wrong, due to the fact there will
'/inc' added. Therefore it looks for some cppunit header files in the wrong
directory like ../../include/inc but there is nothing. But the header files was
found earlier in the old extra directory mentioned at first.

I changed the cppunit-patch this way, I replaced the PRJINC= by INCEXT= which
will add very late in the include directive but will not expand by ''magic''.

For a test of myself, I removed 'SynchronizedObject.h' out of such extra
directory and it builds nevertheless.

HTH.

after the lastest fix:

Making: ../../../../../../unxlngppc.pro/slo/TestResult.obj
g++ -fsigned-char -fmessage-length=0 -c -Os -fno-strict-aliasing   -I. 
-I../../../../../../unxlngppc.pro/inc/c5t_testresult -I../inc
-I../../../../../../inc/pch -I../../../../../../inc -I../../../../../../unx/inc
-I../../../../../../unxlngppc.pro/inc -I.
-I/home/rene/OpenOffice.org/OOO300_m9/solver/300/unxlngppc.pro/inc/stl
-I/home/rene/OpenOffice.org/OOO300_m9/solver/300/unxlngppc.pro/inc/external
-I/home/rene/OpenOffice.org/OOO300_m9/solver/300/unxlngppc.pro/inc
-I/home/rene/OpenOffice.org/OOO300_m9/solenv/unxlngppc/inc
-I/home/rene/OpenOffice.org/OOO300_m9/solenv/inc
-I/home/rene/OpenOffice.org/OOO300_m9/res
-I/home/rene/OpenOffice.org/OOO300_m9/solver/300/unxlngppc.pro/inc/stl
-I/home/rene/OpenOffice.org/OOO300_m9/solenv/inc/Xp31 -INO_JAVA_HOME/include
-INO_JAVA_HOME/include/linux -INO_JAVA_HOME/include/native_threads/include
-I/usr/include 
-I/home/rene/OpenOffice.org/OOO300_m9/solver/300/unxlngppc.pro/inc/offuh
-I../../include -I../../../../../../res -I. -fsigned-char -pipe -frtti  
-Wno-ctor-dtor-privacy   -fPIC -DLINUX -DUNX -DVCL -DGCC -DC300 -DPOWERPC
-DCVER=C300 -DNPTL -DGLIBC=2 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR
-D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DPOWERPC -DPPC
-DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3
-DGXX_INCLUDE_PATH=/usr/include/c++/4.3 -DSUPD=300 -DPRODUCT -DNDEBUG
-DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI   -DSHAREDLIB -D_DLL_  
-fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON  -o
../../../../../../unxlngppc.pro/slo/TestResult.o
/home/rene/OpenOffice.org/OOO300_m9/cppunit/unxlngppc.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp
In file included from ../../include/cppunit/result/TestResult.h:19,
                 from
/home/rene/OpenOffice.org/OOO300_m9/cppunit/unxlngppc.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:3:
../../include/cppunit/result/optionhelper.hxx:39:30: error: testshl/getopt.hxx:
No such file or directory
In file included from
/home/rene/OpenOffice.org/OOO300_m9/cppunit/unxlngppc.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:5:
../../include/cppunit/result/outputter.hxx:39:27: error: testshl/log.hxx: No
such file or directory

missing a dep on testshl2? oh, wait, testshl2 depends on cppunit.

Did anyone even TRY to build this cleanly from scratch?

->rene: next try
I removed the complete header directories cppunit, testshl2, testshl from the
'extra directory' see above issue message. Also found out that some files where
stored in wrong directories. Therefore I had to create a new patch. Now they
will store in the right directories.

lla: yes, that finally builds up to testshl2!

This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues