[cmake-developers] Improved support for using cmake-based libraries in non-cmake projects

[Alexander Neundorf]

On Wednesday 06 July 2011, Alexander Neundorf wrote:
> On Monday 04 July 2011, Brad King wrote:
> > On 07/03/2011 12:23 PM, Alexander Neundorf wrote:
> > > On Monday 20 June 2011, Brad King wrote:
> > >> On 06/17/2011 05:09 PM, Alexander Neundorf wrote:
> > >>> I improved it somewhat, so IMO it is basically working now.
> > >>> There is now a branch UsingCMakeLikePkgConfig on stage.
> > >>> Would be nice if you could have a look.
> > >> 
> > >> The patch series is hard to follow because it adds and removes
> > >> some code/comments and adds a file too late.  Please edit the
> > >> topic with "git rebase -i" to clean it up and push again.
> > > 
> > > There is now a new branch UsingCMakeLikePkgConfig2 in the stage.
> > > It should have somewhat nicer commits.
> > 
> > Much easier, thanks.
> > 
> > > This is not yet ready to be merged, but it would be nice if it could
> > > get a review :-)
> > 
> > In the first commit "Make clLocalGenerator::GetTargetFlags() public"
> > please fix the typo "s/cl/cm/".
> > 
> > In the second commit "Add find-package mode, which does nothing yet"
> > I think we should use an enumeration for the mode rather than separate
> > ScriptMode and FindPackageMode booleans.  It does not make sense to
> > have both at once, so both flags can be replaced by a single enumeration
> > value.
> 
> I'll have a look.

Done. There is now an enum which can have the values SCRIPT_MODE, 
FIND_PACKAGE_MODE and NORMAL_MODE.

> > In the main commit, "Implement find-package mode of cmake", there are
> > some technical challenges remaining:
> > 
> > (1) The code
> > 
> >   # this is ugly, and not enough for the multilib-stuff I guess
> >   if(UNIX AND EXISTS /usr/lib64)
> >   
> >     set(CMAKE_SIZEOF_VOID_P 8)
> >   
> >   endif()
> > 
> > hints at this one.  Some FindXXX modules or XXXConfig.cmake files may
> > switch behavior off the target compiler and architecture.  Without
> > having a real enable_language() the files may not present accurate
> > information.  I don't think a full enable_language can be made to work
> > in this mode, at least not efficiently.  This problem may be a matter
> > of passing more arguments into the mode to tell it things like the
> > address size as necessary.
> 
> Yes. I'll add something.

Done.
So, CMAKE_SIZEOF_VOID_P can be given to the script from the outside via -D.
If this is not done, it checks for /usr/lib64. If found -> 64bit.
If it doesn't exist, it then does /usr/bin/file /usr/bin/file, and checks 
whether the output contains "64-bit". If so -> 64bit.
I think this should work for most cases.
For the remaining cases CMAKE_SIZEOF_VOID_P has to be given from the outside 
(which is a configure script so this shouldn't be a problem).

For the multiarch stuff: the script now uses the regexp as defined in 
Linux.cmake to check whether such a directory exists, and if so, uses the 
first one found.
If there are multiple matching directories, this value again has to be given 
from the outside.

I think both issues above should work for all one-architecture installations.
 
> > (2) In the case that the to-be-found package really does provide a
> > CMake package configuration file (FooConfig.cmake) then it may provide
> > the libraries as imported targets.  The Foo_LIBRARIES variable will
> > contain only the logical names and not any real path information.
> > You'll have to read one of the LOCATION_<CONFIG> properties from
> > such imported targets to get an actual file path.
> 
> This works already.
> I don't simply print the contents of the variable, but an executable target
> is added, and it links against the contents of the variable. Then cmake
> does all the rest and evaluates it, and generates a command line for the
> linker.

Yes, already works :-)

> > (3) This hunk:
> >  +  // free generic one if generated
> >  +//  this->SetGlobalGenerator(0); // setting 0-pointer is not possible
> >  +//  delete gg; // this crashes inside the cmake instance
> > 
> > will require further investigation and/or refactoring of existing
> > code to address.  Perhaps the changes can be included in the second
> > patch or an additional patch in the series.
> 
> I had a look.
> I could simply leave it as it is (and remove the comment), then the global
> generator which is created in this function will be deleted later on by the
> normal cmake dtor.
> 
> Or I can change cmake::SetGlobalGenerator() so that it accepts a 0-pointer
> in findpackage mode, and deletes the old global generator (and call
> SetGlobalGenerator(0) then).
> 
> I'd prefer the first solution, since it doesn't require code changes and
> there shouldn't be an actual problem.

As I said, I think it's ok.
 
> > (4) Tests should be added in another patch after this.  They can wait
> > until the rest has matured though so we know what to test ;)
> 
> Yes :-)

Yes.

Another question: the cmake.m4 is based on the m4-file for pkgconfig, which 
has the GPL header at the top. So, the cmake.m4 still has that header at the 
top.
Is this a problem ?
I don't know how the license of a file, which is installed by cmake, but not 
compiled-in nor used by cmake itself influences cmake.
I thought about asking e.g. on the autoconf list for help, but this is a GNU 
project, so I doubt they will want to help to write a file with a BSD 
license...

Alex