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 _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
