This is a review request for the new CMake based build system for Dogtag. I would like to commit this on Monday, October 18. This doesn't touch the current build system. These are just additional build files. The build system is designed to do an out of source build. So no files in the source directory are added or changed. This build the complete dogtag system in one run. I takes about 1min 20sec here on my notebook. You can find the patches here: http://git.cynapses.org/users/asn/pki.git/log/?h=cmake Some stats: 48 patches 109 files changed, 12166 insertions(+), 4 deletions(-) Build instructions: git clone git://git.cynapses.org/users/asn/pki.git cd pki git checkout -b cmake origin/cmake mkdir build cd build cmake -DCMAKE_INSTALL_PREFIX=/usr -DLIB_SUFFIX=64 .. make -j make -j install
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!