|
Hello Ales,
Thank you for your input! I focused on the technical tasks and forgot the guidelines of GNU :)
In general, I would advice against of having 2 build systems. This makes the maintenance of the project more difficult and the 2 systems might go out of sync eventually. Depending on what are the goals of the project, there are 2 alternatives that I would suggest:
* If it is preferred to use the autoconf tools, then for compiling the project under windows I would use the MinGW project (which also has support for autotools --
http://www.mingw.org/category/wiki/autotools). The main disadvantage of this approach is the compatibility of the dlls. The dlls produced with mingw, I think (I am not 100% certain!), are not compatible with Visual Studio. So they can not be linked against
projects that are being compiled with Visual Studio. Probably for these projects, a C-wrapper can be created, but that complicates a lot the use of the library. If we only want to generate the gama-local.exe, then this is not a problem.
* If it is preferred to move to CMake, then I would create a CMake configure wrapper (e.g.
https://github.com/Richard-W/cmake-configure-wrapper and
https://github.com/nemequ/configure-cmake). That way, the project would be compliant with the GNU standards. But that would introduce a strict external dependency for compiling the project (i.e. installing CMake before compiling the project). Furthermore,
although technically we comply with the GNU guidelines, we might not be following the spirit of the guidelines.
So I really do not know what is the best choice in this case :)
For the rest of the comments:
* If it is decided to move forward with CMake, then I will also be able to test the build in Windows. With Visual Studio I have already experience (conan already provides a windows package for the SQLite3, so it will be easy to test it). As far as it concerns
anacoda, I do not really have any experience. From my research, it is similar to the conan package manager, so probably I will be able to test it.
* If I had to use a metaphor for the target syntax in CMake, I would compare it to the new C++ Standard. The new target syntax was introduced in version 3 of CMake and from my understanding is the preferred way of writing CMake projects.
* I can re-introduce the old libExpat. CMake can examine if there is a local libExpat version, and if there is, use that instead.
* libxml2, octave, SQLite3 are already optional and ignored. The user has to explicit select them, otherwise they are not being used.
* UT = Unit tests. Currently the tests located under the folder statan are not being compiled and executed.
* The Texinfo will remain. I have not find (yet :) ) a way of generating the documentation via CMake.
Kind regards,
Vasileios
On 20/10/19 5:43 μ.μ., Aleš Čepek wrote:
Dear Vasileios, I am impressed (no irony!). I like some of you improvements, but strongly disagree with some of the others. Anyway, thank you for you work a and effort. Let me now explain my main points.
First of all, Gama is a GNU project and its official build is based on GNU Autotools, Cmake is used only for Windows builds of gama-local.exe from MS Visual Studio (Petra Millarova) and last but not least by Anaconda system,
https://anaconda.org/conda-forge/gama/ (Kristian Evers). I am not much familiar with these two platforms, but Petra and Kristian have the final say in the CMake build changes.
Some random comments:
* Start using modern target syntax in CMake ... generally I am for, if Petra and Kristian agree.
* Remove from the source code the old libExpat ... you cannot do this. If you have a look at
configure.ac you can see tha old expat sources are used only in case when expat library is not installed on the system (I do not want the build to fail if this library is missing, I do not want strict
external dependency) * Integrated the libxml2, octave, SQLite3 in CMake ... same as in previous point. Octave and Sqlite3 are optional extensions, if the libraries are not available, these features are simply ignored. ... it would be nice if octave and sqlite3 would be only
optional features in the CMake build (similarly as in the autotools)
* Factor out the common xml headers/sources into a new library.
This was necessary, because there was a cyclical dependency. Now CMake
can auto generate the ellipsoids.h/cpp and the language.h/cpp files
On Sun, 20 Oct 2019 at 16:23, Vasileios-Athanasios Anagnostopoulos < address@hidden> wrote:
Hello Everyone,
As a pet project I started to update the CMake implementation of the
gama project. You can find my progress in
https://github.com/anagno/gama .
* What has been done:
* Start using modern target syntax in CMake
* Remove from the source code the old libExpat
* Integrated the libxml2, octave, SQLite3 in CMake
* Factor out the common xml headers/sources into a new library.
This was necessary, because there was a cyclical dependency. Now CMake
can auto generate the ellipsoids.h/cpp and the language.h/cpp files
during
the generation of the project.
* Integrated the Conan package manager as an optional in CMake
* Migrate the statan UT ... I am not sure with UT abbreviation. As to the statan functions, I don't think they are rich enough to form an individual library (surely I could find a statisticaly library, but why to define another dependency just for a few
simple functions)
* Migrate the generation of the docs in CMake (probably using Doxygen?) ... I do not like Doxygen comments in the source codes, which is not important, what is important is tha Gama as GNU project must come with documentation in Texinfo. This was what
I agreed with before Gama was dubbed a GNU package by rms.
* qt ... this is a special case. I return to Qt application gama-q2 these days but this is not an official part of GNU Gama.
* Test the new build system in Windows ... there is a limited unit test support (compared with autotools tests suite), but I doubt that it is needed to run test on internal matrix algorithms from ctest.
Is this of interest ? ... It is definitely of interest!
* When running the UT with valgrind via CMake ... there are memory leaks ... I would star with this issue, I guess that you detected missing of one delete operator in LocalNetwork::~LocalNetwork() destructor (?) which is allready fixed, but not committed
to git yet.
Aleš
* What still remains:
* Complete the migration of the gama-local UT (not all UT are being
executed via CMake)
* Migrate the statan UT
* Migrate the generation of the docs in CMake (probably using Doxygen?)
* Update the documentation
* I have not examine the qt library of gama and how it can be
integrated with the changes
* Test the new build system in Windows.
* When running the UT with valgrind via CMake (i.e. ctest -j8 -T
memcheck --
https://gitlab.kitware.com/cmake/community/wikis/doc/ctest/Testing-With-CTest#dynamic-analysis),
there are memory leaks. Investigate them and fix them (?)
Is this of interest ? If yes, are they any limitations in my
implementation that I have not considered and should be taken into
consideration?
Have a beautiful week and kind regards,
Vasileios
P.S.: My system is an Ubuntu 18.04 computer, so I am might have miss
some compatibility problems with other linux distros.
P.S.2:This is a pet project, so no promises on when it will be fully done :)
_______________________________________________
Bug-gama mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-gama
|