Re: [cybop-developers] CMake

[Enrico Gallus]

Hi Christian,

Looks like everything is ways easier with the darwin system, because most of the 3rd party libraries are only used for the GNU operating systems.

I also think that we probably get other problems referring the make on a windows system. We should check this out.

The cmake can of course be configured to just include and link libraries for specific architectures.

So we are flexible over here and just need to know what to include.

Sorry for wasting your time with getting the cmake fixed on debian.

Then, there is still a linker error to be fixed (missing XCB lib).
See the following email "CMake Errors”.

Please try this again. I updated the CMakeList.txt file.
It now links several libraries which are used and are defined in the configure.ac. I did not take care of this before, my compiler did not complain at all.

I could fix the following error, by installing the "freeglut3-dev" package:

address@hidden:/home/project/cybop$ cmake .
CMake Error at /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 (message):
 Could NOT find GLUT (missing: GLUT_glut_LIBRARY GLUT_INCLUDE_DIR)
Call Stack (most recent call first):
 /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:343 (_FPHSA_FAILURE_MESSAGE)
 /usr/share/cmake-3.0/Modules/FindGLUT.cmake:93 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
 CMakeLists.txt:18 (find_package)

I could fix the following error by changing the version to "3.0.2":

CMake Error at test/CMakeLists.txt:2 (cmake_minimum_required):
 CMake 3.8.0 or higher is required.  You are running version 3.0.2
Call Stack (most recent call first):
 CMakeLists.txt:53 (include)

But now I get two new errors. The packages are named "libxi" and "libxmu"
on my Debian (stable) system (nothing with GLUT). Both of them are installed.
Nevertheless the errors:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
GLUT_Xi_LIBRARY (ADVANCED)
   linked by target "cyboi" in directory /home/project/cybop
GLUT_Xmu_LIBRARY (ADVANCED)
   linked by target "cyboi" in directory /home/project/cybop

The problem here is that I thought the GLUT and OpenGL libraries are required by cybop. But i failed.

I realised that you use the xcb as an substitution due to some problems you had in the past as mentioned in the opengl_starter.c.

So far i’m not really sure about the dependencies, but as far what i read it rather uses OpenGL than GLUT, right?

I also realised that the only place where the glut was used is a “test”-class. The communicator_tester, but all GLUT-references are commented out.

Looks like cmake is/was aware of this kind of issue https://public.kitware.com/Bug/bug_relationship_graph.php?bug_id=14060&graph=dependency. But the issue was closed.

So we have several opportunities here.

1. We remove the required flag from the glut-library and only keep the required flag on the OpenGL library. Does this reflect the requirements of cybop?

2. We could use the workaround proposed by kit ware in the link above.

3. We could remove the glut-library linking completely 

4. You install the necessary packages by using 'sudo apt-get install libxmu-dev libxi-dev'

I already did 1. and 2. and hopefully this will solve the issue. If not we have to play around with the configuration.

I also changed the structure a little bit and extracted blocks out of the main cmake-file into smaller files.

Maybe it is a bit more readable and self-explaining now.

You find all the library depending definitions in build/libraries.cmake. Feel free to make adjustments if the changes i committed do still not lead to any success to build cybop on debian.

It was too tempting, we talked about code styling checks some time ago and to include it into the build process.

I did some research and found two really helpful tools (cppcheck and clang-format). Both are optional, it is not needed to execute it or to install and i haven’t configured it for the project yet.

You COULD use clang-format (https://clang.llvm.org/docs/ClangFormat.html) in the future to force a specific indent or to force sorted includes and so on.

You COULD use cppcheck (http://cppcheck.sourceforge.net) to detect bugs compilers can’t. Memory leaks and so on.

or CPack and get included in distributable packages.

I already included the whole admin directory in the package.

I removed the "admin/" directory completely. See below.

I adjusted the cpack configuration properly.

In directory "admin/", there is also the VERY old Makefile from 2006.

Do you want to keep the VERY old Makefile? The exclude_include txt files confused me a lot too.

No. I kept the OLD Makefile just as a fallback possibility
(from the time before autotools got introduced).
I have now removed it together with the include and exclude files.

Btw, do you still release three different components (CYBOL, CYBOP, CYBOI)? The process looks like, but the download-section of the homepage has only cybop.
And the content of the tar on the homepage does not match the definition in the makefile somehow. at least, i found some slightly differences.

No. Years ago, I planned to distribute the three separately.
But then, I applied for CYBOP to become an official GNU project
and got some hints from the developers there.
One was to distribute just one tarball for now, as long as
the project is still in alpha phase and relatively small.

I really need some definitions over here, what you expect!

Therefore, you may generate just ONE distributable tarball (tar.gz).
Optionally, if you like and it is possible, a Debian package

Unfortunately I can’t test it, because creating deb packages on mac is not supported, BUT I activated it just by adding “DEB” to the CPACK_GENERATOR list.

and other formats.

I changed the configuration again to just generate one tarball with the content as it is in the current releases.

Some things are gathered more general, like take the whole src-directory. other files are listed single.

You can adjust this to your purpose at all times by manipulating build/packaging.cmake

I kept the former configuration as an example how you later on could easily distribute a tarball for each part. Please have a look at cpack_component_example.cmake.

You can remove it if you think it is not helpful.

If you have a better idea where i.e. into which directory to put these
files (manpages, icons), then please tell me! So we could delete "admin/“.

I created a subfolder CMake to have a place where i could put the FindCBX.cmake. Maybe we can put this manages and icon’s there as well?

I have created a new directory "build/" and moved the file
"FindCBX.cmake" to there. Please forgive me ;)
The name "build" is more neutral and independent from CMake.
Also, only small letters are used for the directory name.

Moreover, I have moved the icons into a subdir "build/icon/"
and the manpages into a subdir "build/manpage/".
I hope you can live with that for now.

Later (some years?), we might have to move the icons into
something like a "share/" directory perhaps, in case the
cyboi executable uses them for a gui or the like.

It’s alright!,this is your project! I used cmake because it represented the configuration for it. but after adding manpages and icons the name was not proper anymore and build suites it pretty well.

I adjusted the cpack-configuration to the renaming of the directory.

- put generated distributable packages or installers into "dist/“

this was quite a bit complicate. the platform dependent package is automatically deployed to dist now (.sh + tar.gz) just using cpack-command (zip, deb-package and other opportunities are possible easily)

If other projects handle this differently or use another directory than
"dist/", so please tell me. Perhaps we can change this to be up-to-date.

The cpack by default generates the release-zip’s to the root directory. Only a strange hack makes it possible to generate it somewhere else. But the release zips are not committed anyway. You are copying it afterwards to the www of the web server, right?

Yes. They are uploaded to the portal, but NOT added to SVN.

However, I of course keep a copy of all files released
in the local project directory "release/“.

So you don’t mind of the tarball get’s generated to the root directory? you just need to copy it to your release folder afterwards.

Maybe we should talk about that later on, when the linking finally works for you and you can cpack it on your system.

I’m sure we can find a solution to reflect your process of releasing the cybop system but therefore you need to be able to execute cpack.

So let’s hope the linking changes i did finally will fix the issues.

BTW, perhaps you could create an entry in the ChangeLog file
(project root directory) whenever you do larger changes?
I have added one entry for you with date 2017-03-06.

Of course, sorry, didn’t know that this needs to be done. Is this just something i should know or is there some kind of instruction?

Regards
Christian

Greetings,

Enrico