Bug 643206

I've been trying this out and have run into an issue.

Since this process currently does not create rpms, there is no way to uninstall a build without the benefit of the rpm database. As a result, I tried changing the CMAKE_INSTALL_PREFIX to /tmp. If I use make -j, this fails very quickly when compiling nsutil. If I remove the -j option, make completes, but make install does not:

CMake Error at base/ra/cmake_install.cmake:48 (FILE):
  file INSTALL cannot find "/local/home/svrbld/pki/base/ra/alias".
Call Stack (most recent call first):
  base/cmake_install.cmake:51 (INCLUDE)
  cmake_install.cmake:37 (INCLUDE)

I'm not sure why the install prefix appears to only work with /usr.

Nice first pass!

I was able to get it to install to "/opt" by doing the following:

    # chmod 777 /opt  (necessary for install)

Then I ran:

    # cmake -DCMAKE_INSTALL_PREFIX=/opt -DLIB_SUFFIX=64 ..
      (since I am using a 64-bit Fedora 12 machine)

Then I ran "make -j", and it kept failing on building "nsutil.jar".  If you run it a second time, it succeeds (although eventually, mine started working the first time).

I was able to get around the problem that you reported above by simply creating the following empty directories in the top-level directories (not under the build directory):

   # mkdir pki/base/ra/alias
   # mkdir pki/base/ra/logs
   # mkdir pki/base/tps/alias
   # mkdir pki/base/tps/logs

NOTE: Although some empty directories were missing from the Java source code
      areas (e. g. - pki/base/ca/shared/alias), they did not seem to create
      any issues during installation.

I then ran "make -j install" and everything got copied under "/opt", although I would think that we are primarily concerned about RPM packaging to deal with all
of the location issues.

Thus far, I have noticed a few things (I have used "/usr" as the prefix in my description for "real" locations):

(1) The "jar" portion of the JNI files are in the wrong location:

        /usr/share/java/pki/osutil.jar --> /usr/lib/java/osutil.jar
        /usr/share/java/pki/symkey.jar --> /usr/lib/java/symkey.jar

    NOTE:  This is true for both 32-bit and 64-bit platforms even though
           the ".so" library portion of the JNI file goes under /usr/lib64
           on 64-bit platforms. Probably a non-issue taken care of by RPM.

(2) Top-level subystem "jar"s go directly under "/usr/share/java", and RPMS
    generate all appropriate symlinks.  Again, probably another non-issue
    addressed by RPM.

(3) I noticed that the generated "jar" files contained numerous extra files.
    For example:

# unzip -l ca.jar
Archive:  ca.jar
  Length     Date   Time    Name
 --------    ----   ----    ----
        0  10-15-10 17:42   META-INF/
       71  10-15-10 17:42   META-INF/MANIFEST.MF
      336  10-15-10 16:59   DependInfo.cmake
      189  10-15-10 16:59   cmake_clean.cmake
        0  10-15-10 17:00   com/
        0  10-15-10 17:00   com/netscape/
        0  10-15-10 17:00   com/netscape/ca/
    15221  10-15-10 17:06   com/netscape/ca/CMSCRLExtensions.class
    25394  10-15-10 17:06   com/netscape/ca/CAService.class
      246  10-15-10 17:06   com/netscape/ca/IServant.class
     3484  10-15-10 17:06   com/netscape/ca/serviceIssue.class
     5536  10-15-10 17:06   com/netscape/ca/serviceRenewal.class
     1500  10-15-10 17:06   com/netscape/ca/getCertsForChallenge.class
     2082  10-15-10 17:06   com/netscape/ca/getCertStatus.class
     4344  10-15-10 17:06   com/netscape/ca/serviceCheckChallenge.class
     3412  10-15-10 17:06   com/netscape/ca/serviceRevoke.class
     3614  10-15-10 17:06   com/netscape/ca/serviceUnrevoke.class
     1418  10-15-10 17:06   com/netscape/ca/serviceGetCAChain.class
     2219  10-15-10 17:06   com/netscape/ca/serviceGetCRL.class
     2141  10-15-10 17:06   com/netscape/ca/serviceGetRevocationInfo.class
     1629  10-15-10 17:06   com/netscape/ca/serviceGetCertificates.class
     3518  10-15-10 17:06   com/netscape/ca/serviceCert4Crl.class
     2550  10-15-10 17:06   com/netscape/ca/serviceUnCert4Crl.class
    10300  10-15-10 17:06   com/netscape/ca/SigningUnit.class
     3735  10-15-10 17:06   com/netscape/ca/CRLIssuingPoint$RevocationRequestListener.class
    46791  10-15-10 17:06   com/netscape/ca/CRLIssuingPoint.class
     5493  10-15-10 17:06   com/netscape/ca/CertRecProcessor.class
     3935  10-15-10 17:06   com/netscape/ca/CAPolicy.class
    42966  10-15-10 17:06   com/netscape/ca/CertificateAuthority.class
      951  10-15-10 17:06   com/netscape/ca/CRLWithExpiredCerts.class
     3517  10-15-10 16:59   build.make
        1  10-15-10 16:59   progress.make
       99  10-15-10 17:00   depend.make
       99  10-15-10 17:00   depend.internal
 --------                   -------
   196791                   34 files

Obviously, the following files should not be included in the jar:

      336  10-15-10 16:59   DependInfo.cmake
      189  10-15-10 16:59   cmake_clean.cmake
     3517  10-15-10 16:59   build.make
        1  10-15-10 16:59   progress.make
       99  10-15-10 17:00   depend.make
       99  10-15-10 17:00   depend.internal

(4) The "pkicreate", "pkiremove", and "pkihost" Perl scripts do not contain
    execute permission, and the shared "pkicommon" Perl script is located
    under "/bin" instead of "/usr/share/pki/scripts/pkicommon".

(5) The "pki-migrate" code is no longer a part of Dogtag on Fedora platforms;
    it is only included with RHCS on Red Hat platforms, as these refer to
    data migration from earlier proprietary versions of Certificate System.

(6) The "pki-native-tools" located under "/bin" are intended to be wrappers,
    which point to either 64-bit exectuables under
    "/usr/lib64/pki/native-tools", or 32-bit executables under
    "/usr/lib/pki/native-tools".

I am currently working on the commands necessary to generate a "mock" environment to better test out the "install" process (although this would
be useful even once we have RPMS available).

(In reply to comment #2)
> Nice first pass!

Thanks and thanks for the feedback. See details below.
 
> I was able to get it to install to "/opt" by doing the following:
> 
>     # chmod 777 /opt  (necessary for install)
> 

Well, normally you simply do: sudo make install

> Then I ran:
> 
>     # cmake -DCMAKE_INSTALL_PREFIX=/opt -DLIB_SUFFIX=64 ..
>       (since I am using a 64-bit Fedora 12 machine)
> 
> Then I ran "make -j", and it kept failing on building "nsutil.jar".  If you run
> it a second time, it succeeds (although eventually, mine started working the
> first time).

Which was the error? I need more details here. It works just fine here ...

> I was able to get around the problem that you reported above by simply creating
> the following empty directories in the top-level directories (not under the
> build directory):
> 
>    # mkdir pki/base/ra/alias
>    # mkdir pki/base/ra/logs
>    # mkdir pki/base/tps/alias
>    # mkdir pki/base/tps/logs

These directories do exist here. I haven't created them.

The directories exist in the SVN repo too:

https://fedorahosted.org/pki/browser/trunk/pki/base/ra
https://fedorahosted.org/pki/browser/trunk/pki/base/tps

> NOTE: Although some empty directories were missing from the Java source code
>       areas (e. g. - pki/base/ca/shared/alias), they did not seem to create
>       any issues during installation.

base/ca/shared/alias exists here too.

> 
> I then ran "make -j install" and everything got copied under "/opt", although I
> would think that we are primarily concerned about RPM packaging to deal with
> all
> of the location issues.
> 
> Thus far, I have noticed a few things (I have used "/usr" as the prefix in my
> description for "real" locations):
> 
> (1) The "jar" portion of the JNI files are in the wrong location:
> 
>         /usr/share/java/pki/osutil.jar --> /usr/lib/java/osutil.jar
>         /usr/share/java/pki/symkey.jar --> /usr/lib/java/symkey.jar
> 
>     NOTE:  This is true for both 32-bit and 64-bit platforms even though
>            the ".so" library portion of the JNI file goes under /usr/lib64
>            on 64-bit platforms. Probably a non-issue taken care of by RPM.

Fixed.
 
> (2) Top-level subystem "jar"s go directly under "/usr/share/java", and RPMS
>     generate all appropriate symlinks.  Again, probably another non-issue
>     addressed by RPM.

What do you mean? They are installed in <prefix>/share/java. If they need to be in a special location, then I need a way to ask the installed java version where to install it. Something like:

'perl -V:installsitelib'

> 
> (3) I noticed that the generated "jar" files contained numerous extra files.
>     For example:

I've fixed this on Saturday.

> (4) The "pkicreate", "pkiremove", and "pkihost" Perl scripts do not contain
>     execute permission, and the shared "pkicommon" Perl script is located
>     under "/bin" instead of "/usr/share/pki/scripts/pkicommon".

Fixed.

> (5) The "pki-migrate" code is no longer a part of Dogtag on Fedora platforms;
>     it is only included with RHCS on Red Hat platforms, as these refer to
>     data migration from earlier proprietary versions of Certificate System.

Fixed.

> (6) The "pki-native-tools" located under "/bin" are intended to be wrappers,
>     which point to either 64-bit exectuables under
>     "/usr/lib64/pki/native-tools", or 32-bit executables under
>     "/usr/lib/pki/native-tools".

It doesn't make sense to me using wrappers for these binaries. Can you please tell me why these wrappper scripts are needed?

(In reply to comment #1)
> I've been trying this out and have run into an issue.
> 
> Since this process currently does not create rpms, there is no way to uninstall
> a build without the benefit of the rpm database. As a result, I tried changing
> the CMAKE_INSTALL_PREFIX to /tmp. If I use make -j, this fails very quickly
> when compiling nsutil. If I remove the -j option, make completes, but make
> install does not:

What the error when compiling nsutil?

> CMake Error at base/ra/cmake_install.cmake:48 (FILE):
>   file INSTALL cannot find "/local/home/svrbld/pki/base/ra/alias".
> Call Stack (most recent call first):
>   base/cmake_install.cmake:51 (INCLUDE)
>   cmake_install.cmake:37 (INCLUDE)
> 
> I'm not sure why the install prefix appears to only work with /usr.

I don't understand why you don't have have this directory. I can see it on my filesystem and in subversion.

I've added a 'make uninstall' target. What you can always to is:

xargs rm < install_manifest.txt

(In reply to comment #3)
> (In reply to comment #2)
> > Nice first pass!
> 
> Thanks and thanks for the feedback. See details below.
> 
> > I was able to get it to install to "/opt" by doing the following:
> > 
> >     # chmod 777 /opt  (necessary for install)
> > 
> 
> Well, normally you simply do: sudo make install
> 
> > Then I ran:
> > 
> >     # cmake -DCMAKE_INSTALL_PREFIX=/opt -DLIB_SUFFIX=64 ..
> >       (since I am using a 64-bit Fedora 12 machine)
> > 
> > Then I ran "make -j", and it kept failing on building "nsutil.jar".  If you run
> > it a second time, it succeeds (although eventually, mine started working the
> > first time).
> 
> Which was the error? I need more details here. It works just fine here ...
> 

When I first did this, it was always failing on "nsutil.jar".  As I stated, it simply began to work before I could capture the error message to place in to this bug.  If I see this issue again, I will be sure to grab it and post it to the bug.

> > I was able to get around the problem that you reported above by simply creating
> > the following empty directories in the top-level directories (not under the
> > build directory):
> > 
> >    # mkdir pki/base/ra/alias
> >    # mkdir pki/base/ra/logs
> >    # mkdir pki/base/tps/alias
> >    # mkdir pki/base/tps/logs
> 
> These directories do exist here. I haven't created them.
> 
> The directories exist in the SVN repo too:
> 
> https://fedorahosted.org/pki/browser/trunk/pki/base/ra
> https://fedorahosted.org/pki/browser/trunk/pki/base/tps
> 

They did not exist on my machine when I ran the instructions above.  As I stated above, I had to create these directories manually.

> > NOTE: Although some empty directories were missing from the Java source code
> >       areas (e. g. - pki/base/ca/shared/alias), they did not seem to create
> >       any issues during installation.
> 
> base/ca/shared/alias exists here too.
> 

Once again, empty directories did not appear to get generated by following your instructions above --- is there some special "git" flag that needs to be set for it to copy "empty" directories?

> > 
> > I then ran "make -j install" and everything got copied under "/opt", although I
> > would think that we are primarily concerned about RPM packaging to deal with
> > all
> > of the location issues.
> > 
> > Thus far, I have noticed a few things (I have used "/usr" as the prefix in my
> > description for "real" locations):
> > 
> > (1) The "jar" portion of the JNI files are in the wrong location:
> > 
> >         /usr/share/java/pki/osutil.jar --> /usr/lib/java/osutil.jar
> >         /usr/share/java/pki/symkey.jar --> /usr/lib/java/symkey.jar
> > 
> >     NOTE:  This is true for both 32-bit and 64-bit platforms even though
> >            the ".so" library portion of the JNI file goes under /usr/lib64
> >            on 64-bit platforms. Probably a non-issue taken care of by RPM.
> 
> Fixed.
> 
> > (2) Top-level subystem "jar"s go directly under "/usr/share/java", and RPMS
> >     generate all appropriate symlinks.  Again, probably another non-issue
> >     addressed by RPM.
> 
> What do you mean? They are installed in <prefix>/share/java. If they need to be
> in a special location, then I need a way to ask the installed java version
> where to install it. Something like:
> 
> 'perl -V:installsitelib'
> 

Last week, when I performed an installation, the jar files created were placed under "<prefix>/share/java/pki" rather than "<prefix>/share/java".

The "<prefix>/share/java/pki" directory contains numerous symlinks for backwards compatibility (which can all be handled via RPM packaging).

> > 
> > (3) I noticed that the generated "jar" files contained numerous extra files.
> >     For example:
> 
> I've fixed this on Saturday.
> 
> > (4) The "pkicreate", "pkiremove", and "pkihost" Perl scripts do not contain
> >     execute permission, and the shared "pkicommon" Perl script is located
> >     under "/bin" instead of "/usr/share/pki/scripts/pkicommon".
> 
> Fixed.
> 
> > (5) The "pki-migrate" code is no longer a part of Dogtag on Fedora platforms;
> >     it is only included with RHCS on Red Hat platforms, as these refer to
> >     data migration from earlier proprietary versions of Certificate System.
> 
> Fixed.
> 
> > (6) The "pki-native-tools" located under "/bin" are intended to be wrappers,
> >     which point to either 64-bit exectuables under
> >     "/usr/lib64/pki/native-tools", or 32-bit executables under
> >     "/usr/lib/pki/native-tools".
> 
> It doesn't make sense to me using wrappers for these binaries. Can you please
> tell me why these wrappper scripts are needed?

Certificate System used to be required to be supported on platforms other than Linux and potentially needed to support both 32-bit and 64-bit versions of the tools simultaneously.  Wrappers were chosen as the way to address this, since the java-based tools required wrappers anyway.

(In reply to comment #5)
> When I first did this, it was always failing on "nsutil.jar".  As I stated, it
> simply began to work before I could capture the error message to place in to
> this bug.  If I see this issue again, I will be sure to grab it and post it to
> the bug.
> 

Great thanks. It is possible that this has already been fixed. I remember that there was a missing dependency.

> They did not exist on my machine when I ran the instructions above.  As I
> stated above, I had to create these directories manually.

Maybe you have a different git version and it didn't create the empty directories for some reason.
 
> > > NOTE: Although some empty directories were missing from the Java source code
> > >       areas (e. g. - pki/base/ca/shared/alias), they did not seem to create
> > >       any issues during installation.
> > 
> > base/ca/shared/alias exists here too.
> > 
> 
> Once again, empty directories did not appear to get generated by following your
> instructions above --- is there some special "git" flag that needs to be set
> for it to copy "empty" directories?
> 

Not that I'm aware of.

> Certificate System used to be required to be supported on platforms other than
> Linux and potentially needed to support both 32-bit and 64-bit versions of the
> tools simultaneously.  Wrappers were chosen as the way to address this, since
> the java-based tools required wrappers anyway.

This sounds like a bug in the design of the platform. So in my opinion it should be fixed by the packagers on that platform. If you insist to use the wrapper we can do that. I'm sure that rpmlint will not be happy with the binary locations in /usr/lib :)

Can I commit the code to the svn repository?

I've added version support for jar files too now.

Created attachment 464321 [details]
changes to legacy build system

TIP:

# cd pki

# svn status | grep -v ^$ | grep -v ^P | grep -v ^X | grep -v ^?
M       dogtag/ra/pki-ra.spec
M       dogtag/tps/pki-tps.spec
M       dogtag/ca/pki-ca.spec
M       dogtag/common/pki-common.spec
M       dogtag/setup/pki-setup.spec
M       dogtag/tks/pki-tks.spec
M       dogtag/ocsp/pki-ocsp.spec
M       dogtag/kra/pki-kra.spec
D       dogtag/console-ui/src/CMSAdminRS.properties
D       base/ca/setup/config.desktop
M       base/ca/build.xml
D       base/setup/pkihost
D       base/tks/setup/config.desktop
M       base/tks/build.xml
M       base/ra/setup/config.desktop.in
D       base/ra/setup/config.desktop
M       base/ra/build.xml
D       base/ocsp/setup/config.desktop
M       base/ocsp/build.xml
M       base/tps/Makefile.in
M       base/tps/build.xml
M       base/tps/setup/config.desktop.in
D       base/tps/setup/config.desktop
M       base/tps/Makefile.am
D       base/kra/setup/config.desktop
M       base/kra/build.xml

# svn commit
Sending        base/ca/build.xml
Deleting       base/ca/setup/config.desktop
Sending        base/kra/build.xml
Deleting       base/kra/setup/config.desktop
Sending        base/ocsp/build.xml
Deleting       base/ocsp/setup/config.desktop
Sending        base/ra/build.xml
Deleting       base/ra/setup/config.desktop
Sending        base/ra/setup/config.desktop.in
Deleting       base/setup/pkihost
Sending        base/tks/build.xml
Deleting       base/tks/setup/config.desktop
Sending        base/tps/Makefile.am
Sending        base/tps/Makefile.in
Sending        base/tps/build.xml
Deleting       base/tps/setup/config.desktop
Sending        base/tps/setup/config.desktop.in
Sending        dogtag/ca/pki-ca.spec
Sending        dogtag/common/pki-common.spec
Deleting       dogtag/console-ui/src/CMSAdminRS.properties
Sending        dogtag/kra/pki-kra.spec
Sending        dogtag/ocsp/pki-ocsp.spec
Sending        dogtag/ra/pki-ra.spec
Sending        dogtag/setup/pki-setup.spec
Sending        dogtag/tks/pki-tks.spec
Sending        dogtag/tps/pki-tps.spec
Transmitting file data ..................
Committed revision 1597.

Created attachment 465110 [details]
changes to cmake build system

This attachment provides the following:

 * changes JNI libraries/jar files/symlinks packaging logic to comply with
   "http://fedoraproject.org/wiki/Packaging:Java"
 * adds an OpenLDAP cmake Module (obtained from KDE)
 * updates NSS cmake Module to include "nssutil3.so" library
 * updates all product versions to 9.0.0
 * restructures installation layout to sync up with desired RPM packaging
 * adds the following new RPM spec files
   * osutil.spec
     * osutil
   * ipa-pki-theme.spec
     * null-pki-common-theme
     * null-pki-ca-theme
   * dogtag-pki-theme.spec
     * dogtag-pki-common-theme
     * dogtag-pki-ca-theme
     * dogtag-pki-kra-theme
     * dogtag-pki-ocsp-theme
     * dogtag-pki-ra-theme
     * dogtag-pki-tks-theme
     * dogtag-pki-tps-theme
   * pki-core.spec
     * pki-setup
     * pki-symlink
     * pki-native-tools
     * pki-util
     * pki-util-javadoc (TBD)
     * pki-java-tools
     * pki-java-tools-javadoc (TBD)
     * pki-common
     * pki-common-javadoc (TBD)
     * pki-selinux
     * pki-ca
     * pki-silent
 * provides optional developer helper scripts for generating RPMS/SRPMS
   using these new spec files

TIP:

# cd pki

# svn status | grep -v ^$ | grep -v ^P | grep -v ^X | grep -v ^?
M       cmake/Modules/FindNSS.cmake
A       cmake/Modules/FindLdap.cmake
M       cmake/Modules/UseJava.cmake
M       dogtag/CMakeLists.txt
M       dogtag/console-ui/src/CMakeLists.txt
M       dogtag/console-ui/CMakeLists.txt
M       CPackConfig.cmake
A       scripts
A       scripts/compose_ipa_pki_theme_packages
A       scripts/compose_osutil_packages
A       scripts/compose_dogtag_pki_theme_packages
A       scripts/compose_pki_core_packages
M       base/osutil/src/CMakeLists.txt
M       base/osutil/src/com/netscape/osutil/CMakeLists.txt
M       base/osutil/CMakeLists.txt
M       base/java-tools/src/CMakeLists.txt
M       base/symkey/src/CMakeLists.txt
M       base/symkey/src/com/netscape/symkey/CMakeLists.txt
M       base/symkey/CMakeLists.txt
M       base/ca/setup/CMakeLists.txt
M       base/ca/src/CMakeLists.txt
M       base/ca/CMakeLists.txt
M       base/native-tools/src/tkstool/CMakeLists.txt
M       base/native-tools/src/setpin/CMakeLists.txt
M       base/native-tools/src/bulkissuance/CMakeLists.txt
M       base/selinux/src/CMakeLists.txt
M       base/selinux/CMakeLists.txt
M       base/common/src/CMakeLists.txt
M       base/common/CMakeLists.txt
M       base/silent/src/CMakeLists.txt
M       base/silent/CMakeLists.txt
M       base/setup/pkicreate
M       base/setup/CMakeLists.txt
M       base/tks/setup/CMakeLists.txt
M       base/tks/src/CMakeLists.txt
M       base/tks/CMakeLists.txt
M       base/ra/setup/CMakeLists.txt
M       base/ra/CMakeLists.txt
M       base/ocsp/setup/CMakeLists.txt
M       base/ocsp/src/CMakeLists.txt
M       base/ocsp/CMakeLists.txt
M       base/tps/CMakeLists.txt
M       base/tps/setup/CMakeLists.txt
M       base/kra/setup/CMakeLists.txt
M       base/kra/src/CMakeLists.txt
M       base/kra/CMakeLists.txt
M       base/util/src/CMakeLists.txt
M       base/CMakeLists.txt
M       CMakeLists.txt
A       specs
A       specs/dogtag-pki-theme.spec
A       specs/pki-core.spec
A       specs/ipa-pki-theme.spec
A       specs/osutil.spec

# svn commit
Sending        CMakeLists.txt
Sending        CPackConfig.cmake
Sending        base/CMakeLists.txt
Sending        base/ca/CMakeLists.txt
Sending        base/ca/setup/CMakeLists.txt
Sending        base/ca/src/CMakeLists.txt
Sending        base/common/CMakeLists.txt
Sending        base/common/src/CMakeLists.txt
Sending        base/java-tools/src/CMakeLists.txt
Sending        base/kra/CMakeLists.txt
Sending        base/kra/setup/CMakeLists.txt
Sending        base/kra/src/CMakeLists.txt
Sending        base/native-tools/src/bulkissuance/CMakeLists.txt
Sending        base/native-tools/src/setpin/CMakeLists.txt
Sending        base/native-tools/src/tkstool/CMakeLists.txt
Sending        base/ocsp/CMakeLists.txt
Sending        base/ocsp/setup/CMakeLists.txt
Sending        base/ocsp/src/CMakeLists.txt
Sending        base/osutil/CMakeLists.txt
Sending        base/osutil/src/CMakeLists.txt
Sending        base/osutil/src/com/netscape/osutil/CMakeLists.txt
Sending        base/ra/CMakeLists.txt
Sending        base/ra/setup/CMakeLists.txt
Sending        base/selinux/CMakeLists.txt
Sending        base/selinux/src/CMakeLists.txt
Sending        base/setup/CMakeLists.txt
Sending        base/setup/pkicreate
Sending        base/silent/CMakeLists.txt
Sending        base/silent/src/CMakeLists.txt
Sending        base/symkey/CMakeLists.txt
Sending        base/symkey/src/CMakeLists.txt
Sending        base/symkey/src/com/netscape/symkey/CMakeLists.txt
Sending        base/tks/CMakeLists.txt
Sending        base/tks/setup/CMakeLists.txt
Sending        base/tks/src/CMakeLists.txt
Sending        base/tps/CMakeLists.txt
Sending        base/tps/setup/CMakeLists.txt
Sending        base/util/src/CMakeLists.txt
Adding         cmake/Modules/FindLdap.cmake
Sending        cmake/Modules/FindNSS.cmake
Sending        cmake/Modules/UseJava.cmake
Sending        dogtag/CMakeLists.txt
Sending        dogtag/console-ui/CMakeLists.txt
Sending        dogtag/console-ui/src/CMakeLists.txt
Adding         scripts
Adding         scripts/compose_dogtag_pki_theme_packages
Adding         scripts/compose_ipa_pki_theme_packages
Adding         scripts/compose_osutil_packages
Adding         scripts/compose_pki_core_packages
Adding         specs
Adding         specs/dogtag-pki-theme.spec
Adding         specs/ipa-pki-theme.spec
Adding         specs/osutil.spec
Adding         specs/pki-core.spec
Transmitting file data ....................................................
Committed revision 1607.

Created attachment 467558 [details]
changes to cmake build system (prevent class replication in jars)

This attachment provides the following:

* logic to prevent duplication of classes within targets that build multiple jars:
  (e. g. - certsrv.jar contains com.netscape.certsrv.*.class
           cms.jar     contains com.netscape.cms.*.class +
                                com.netscape.certsrv.*.class
           cmscore.jar contains com.netscape.cmscore.*.class +
                                com.netscape.cms.*.class +
                                com.netscape.certsrv.*.class)
* added additional JNI symlink at JAR/SHARED LIBRARY level for JNI libraries
* cleaned up some minor dependency issues

TIP:

# cd pki

# svn status | grep -v ^$ | grep -v ^P | grep -v ^X | grep -v ^?
M       cmake/Modules/UseJavaClassFilelist.cmake
M       cmake/Modules/UseJava.cmake
M       base/java-tools/src/CMakeLists.txt
M       base/common/src/CMakeLists.txt
M       base/silent/src/CMakeLists.txt
M       base/util/src/CMakeLists.txt
M       CMakeLists.txt
M       specs/pki-core.spec
M       specs/osutil.spec

# svn commit
Sending        CMakeLists.txt
Sending        base/common/src/CMakeLists.txt
Sending        base/java-tools/src/CMakeLists.txt
Sending        base/silent/src/CMakeLists.txt
Sending        base/util/src/CMakeLists.txt
Sending        cmake/Modules/UseJava.cmake
Sending        cmake/Modules/UseJavaClassFilelist.cmake
Sending        specs/osutil.spec
Sending        specs/pki-core.spec
Transmitting file data .........
Committed revision 1612.

Per information from asn, I generated a replacement for the "cmake/Modules/FindLdap.cmake file using the 'generate_findpackage_file' ruby script.

Created attachment 470034 [details]
patch to honor DESTDIR during empty directory install.

The documentation here:

http://pki.fedoraproject.org/wiki/PKI_Components_Collectively_via_Subversion

needs to be updated.

attachment 470034 [details]

setup$ svn commit CMakeLists.txt 
Waiting for Emacs...
Sending        CMakeLists.txt
Transmitting file data .
Committed revision 1678.

Per previous discussions, I have removed the library versioning from the 'pki-symkey' JNI library:

# cd pki


# svn status | grep -v ^$ | grep -v ^P | grep -v ^X | grep -v ^?
M       base/symkey/src/com/netscape/symkey/CMakeLists.txt
M       base/symkey/CMakeLists.txt


# svn diff base/symkey/CMakeLists.txt
Index: base/symkey/CMakeLists.txt
===================================================================
--- base/symkey/CMakeLists.txt	(revision 1695)
+++ base/symkey/CMakeLists.txt	(working copy)
@@ -1,7 +1,6 @@
 project(symkey)
 
 set(SYMKEY_LIBRARY_VERSION 9.0.0)
-set(SYMKEY_LIBRARY_SOVERSION 9)
 
 add_subdirectory(src)
 add_subdirectory(src/com/netscape/symkey)


# svn diff base/symkey/src/com/netscape/symkey/CMakeLists.txt
Index: base/symkey/src/com/netscape/symkey/CMakeLists.txt
===================================================================
--- base/symkey/src/com/netscape/symkey/CMakeLists.txt	(revision 1695)
+++ base/symkey/src/com/netscape/symkey/CMakeLists.txt	(working copy)
@@ -52,10 +52,6 @@
 
 set_target_properties(${SYMKEY_SHARED_LIBRARY}
     PROPERTIES
-        VERSION
-            ${SYMKEY_LIBRARY_VERSION}
-        SOVERSION
-            ${SYMKEY_LIBRARY_SOVERSION}
         OUTPUT_NAME
             symkey
 )


# svn commit
Sending        base/symkey/CMakeLists.txt
Sending        base/symkey/src/com/netscape/symkey/CMakeLists.txt
Transmitting file data ..
Committed revision 1696.

NOTE:  The 'osutil' JNI library will also have its versioning removed, but
       the source code will be relocated to a 'GIT' repository first!