On Wednesday 24 February 2010 09:58:17 Jan-Oliver Wagner wrote: > since it seemed to have not created much headache to users > and packagers that we introduced cmake to some of the modules > inside openvas-libraries, I propose that we do the final > step and migrate openvas-libraries to cmake. > Thus get rid of the old autotools framework. > > This step needs two groups: > * the developers who do the actual change to cmake > * the users/packagers who test on their systems whether > it works as expected.
Although imho not a fun project, the first part could be proposed as gsoc idea, in combination with my proposals below. Maybe there is a cmake- and build-system crazy student out there (plus we get accepted for gsoc). > The bigger challenge is the main cmake process. > The autotools create several variables etc. of which > some are important and some might be old unneeded > stuff. > I wonder wether it is possible to have a cmake process > in parallet, so that for configuring the system you > can either run cmake or run ./configure. > Might be helpful for the transition phase. CMake has a more or less direct counterpart of the configure step (e.g. with creating a config.h, setting macros etc). I expect the main work to be to find out which variables are actually still needed, correlating with which platforms we want to (or can) support. For this, the second mentioned group above (people doing functional tests on various systems/platforms/architectures) is crucial to have. To make the idea bigger, the process can be expanded to the code base, as code blocks that are #ifdef'd with "outdated" macros might be found. Otherwise we will keep carrying unused code around. I would also propose to keep working on a common cmake file (e.g. in direction of the patch and additional file i attached to http://wald.intevation.org/tracker/index.php?func=detail&aid=1245&group_id=29&atid=220). This would help to stop the diverging CMakeLists.txt in manager, administrator and libraries. And in the same time .pc pkg-info files and the respective FindOpenVAS-library.cmake module could be created/extended to allow easy integration of openvas-libraries into other cmake-based projects. E.g. currently with cmake 2.6 checking for the openvas-libraries version is a real pain. Afaiu, the openvas-libraries.pc created by kost is already pretty useable, just has to get installed and used. -- felix -- Felix Wolfsteller | ++49 541 335083-783 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner _______________________________________________ Openvas-devel mailing list Openvas-devel@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
