[Pki-devel] CMake and eclipse

[Adam Young]

I've spent a good amopunt of time over the last couple of days trying to 
come up with a strategy for integrating PKI development with Eclipse.  
I've learned a great bit in the interim and I'd like to share.  I'm also 
soliciting some guidance on how to proceed.

First, what I've learned:  There are aspects to our cmake  system that 
we are not documenting in the Development section of the website.  
Probably the most basic is how to do incremental builds, which will 
really speed up certain aspects of development.

  If you have the code checked out to ~/workspace/pki, the rpms will be 
built in ~/workspace/packages  and related directories (packages.core, 
packages.kra and so on).

It is not necessary to install the RPMs in order to compile the code.  
One approach would be to create a directory structure parallel to what 
the RPM compose scripts do:

mkdir workspace/build-pki
mkdir workspace/build-pki/core
mkdir workspace/build-pki/kra

then to compile the core code:
cd ~/workspace/build-pki/core
cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_CORE:BOOL=ON  ../../pki
make

A comparable set of lines for KRA is

cd ~/workspace/build-pki/kra
cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_KRA:BOOL=ON  ../../pki
make

These lines can be found in the spec files, under the build sections.  
For example, in
pki/specs/pki-core.spec

cd build
%cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_CORE:BOOL=ON ..
%{__make} VERBOSE=1 %{?_smp_mflags}


CMake generats the Makefile etc in what it refers to as "OutOfSource" 
mode.  This means that, while Make is executed in 
workspace/build-pki/core,  the source remains in 
workspace/pki/base/core.  This is a "best practice" to keep the 
Generated files separate from the revision controlled files.  The PKI 
CMake setup  insists on building the code outside of the source tree.  
This is enforced by  the line  pki/CMakeLists.txt line 69
include(MacroEnsureOutOfSourceBuild).

Changes made in the original source tree are picked up via Makefile 
rules.  This includes changes to the CMake infrastructure, meaning that 
configuration changes trigger a complete build.  This is one of the 
positive aspects of CMake.



CMake knows about eclipse, and has support for generating a project file 
for C and C++ Development.  To configure this:

  cd ~/workspace/build-pki/core
  cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_CORE:BOOL=ON  -G"Eclipse 
CDT4 - Unix Makefiles"  ../../pki/

This can then be imported into Eclipse.  However, the project is a CDT 
project, not a Java project, and is not really a good match for Java 
development.  Some of the shortcomings are that it does not provide 
automated refactorings or Type navigation.

Ideally, we would have separate projects for the C code and the Java 
code, and let each live under the rules most appropriate to it.

This is where the request for guidance comes from.  I think the right 
approach is to modify the CMake approach to split out the C code from 
the rest of the Java code.  The native tools can still remain in the 
same source RPM, but would have their own build step, something like:

cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_NATIVE:BOOL=ON
make

For Java development, I'd ideally like to run an embedded tomcat.  I'm 
not there yet:  I think I need the target code in the form of a web 
archive, in the format that it lives in under 
/usr/share/pki/ca/webapps.  This structure is set up by cmake baswed on 
the code in base/ca/CMakeLists.txt, but does not, as far as I can tell, 
show up in the target tree.  I suspect that the approach would be to 
redefine the install directory for a cmake invocation  to be the same as 
the build directory, or some other non-system owned directory.

Making a Java project throws another curveball here.  Since a Java 
project can't yet be autogenerated from CMake, it probably makes sense 
to check in the .project and .classpath files used.  I've submitted one 
patch in the past that puts the whole tree into  as single project.  I 
could see continuing on this approach, and removing the C files from the 
build tree so that the CDT project.  Even better would be to create one 
project per end RPM, or jar file, and collect them up into a single 
Eclipse workspace, and/or working set.   I think that this is the right 
approach.  I have set separate Java projects for


  base/ca
  base/common
  base/console
  base/java-tools
  base/ocsp
  base/silent
  base/symkey
  base/tks
  base/util


  base/tps  Should be a CDT project as well.  This is pretty well supported:

  cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_TPS:BOOL=ON  -G"Eclipse 
CDT4 - Unix Makefiles"   ../../pki/