Re: [cybop-developers] CMake Linking

[Christian Heller]

Hi Enrico,

> 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.

Well, the student group dealing with compilation under Windows three
years ago was using Visual Studio that brings its own compiler and
build environment. So I guess CMake is not needed there.

However, if creating a Windows executable, I currently use MinGW
(described in the INSTALL file of the project root directory:
i686-w64-mingw32-gcc -o src/controller/cyboi.exe src/controller/cyboi.c -static 
-lpthread -lws2_32 -lgdi32 -w

I am not sure anymore in how far this is related to autotools.
But if CMake shall become our new build system, then of course
the MinGW should be usable OR (better) a native compilation
under Visual C on Windows should be possible.

> 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.

That's very good.

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

If there is progress in the project on the other hand, then it's
always worth it :)

> 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.

Yes, I read about concurrent access issues in Xlib and therefore
switched to XCB. Also, it is slimmer and easier to use than
Xlib and will probably be the future.

> 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.

It's easy to say. CYBOI should cover all communication channels.
- TUI: termios struct for terminal, win32api console, working on Linux
- WUI: standard bsd socket, winsock2 under win32, working for TCP on Linux
- GUI: XCB (as replacement for Xlib), win32 api gui, prepared for XCB
- OpenGL: requires a working GUI first, task for the far future
- possibly others ...

So, TUI and WUI work with prototypes. GUI does not yet completely.
OpenGL (or Vulcan) was only a test some years ago and is for the
future only. I could remove it for now, but one day we will need it.

Suggestion: I try to get CMake work on my system.
Only if the linking problems remain, I will remove any
dependency from OpenGL, FreeGLUT etc. in CYBOI for now.
If the CMake works, I leave everything as it is.

> 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?

No idea. As said above, OpenGL/GLUT is for the future.
We might remove any dependency, if necessary.

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

I don't like workarounds. Sounds dirty and complicating somwhow.

> 3. We could remove the glut-library linking completely

Yes, we could, if necessary. But one day we might need it anyway.

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

I could install these packages, but it worked without having to:

address@hidden:/home/project/cybop$ cmake .
-- Could NOT find PkgConfig (missing:  PKG_CONFIG_EXECUTABLE)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/project/cybop

address@hidden:/home/project/cybop$ make
Scanning dependencies of target constant_test
[ 25%] Building C object 
CMakeFiles/constant_test.dir/test/constant/constant_tester.c.o
Linking C executable test/constant_test
[ 25%] Built target constant_test
Scanning dependencies of target cyboi
[ 50%] Building C object CMakeFiles/cyboi.dir/src/controller/cyboi.c.o
Linking C executable src/controller/cyboi
[ 50%] Built target cyboi
Scanning dependencies of target integer_calculator_test
[ 75%] Building C object 
CMakeFiles/integer_calculator_test.dir/test/executor/calculator/integer_calculator_tester.c.o
Linking C executable test/integer_calculator_test
[ 75%] Built target integer_calculator_test
Scanning dependencies of target variable_test
[100%] Building C object 
CMakeFiles/variable_test.dir/test/variable/variable_tester.c.o
Linking C executable test/variable_test
[100%] Built target variable_test

address@hidden:/home/project/cybop$ cpack
CPack: Create package using TGZ
CPack: Install projects
CPack: - Run preinstall target for: cybop
CPack: - Install project: cybop
CMake Error at /home/project/cybop/cmake_install.cmake:36 (file):
  file INSTALL cannot find "/home/project/cybop/src/Controller/cyboi".
CPack Error: Error when generating package: CYBOP

Due to the error I fixed the file "cpack_component_example.cmake",
line 20, and file "packaging.cmake", line 17, by writing "controller"
in small letters. Afterwards, the "cpack" worked without errors:

address@hidden:/home/project/cybop$ cpack
CPack: Create package using TGZ
CPack: Install projects
CPack: - Run preinstall target for: cybop
CPack: - Install project: cybop
CPack: Create package
CPack: - package: /home/project/cybop/CYBOP-0.19.0-Linux.tar.gz generated.
CPack: Create package using DEB
CPack: Install projects
CPack: - Run preinstall target for: cybop
CPack: - Install project: cybop
CPack: Create package
CPack: - package: /home/project/cybop/CYBOP-0.19.0-Linux.deb generated.

The tar.gz and deb files are at there place, in the project root.
All is fine. But some time ago, I was told that the executable
should not be part of the tarball. So perhaps you remove it?
The reason probably is that e.g. Debian developers only need
a source tarball and the compilation is done by them.

The only remaining thing now seems to be the cmake error:
"Could NOT find PkgConfig (missing:  PKG_CONFIG_EXECUTABLE)"

And one more thing:
I can start the compiled CYBOI and it prints the help message.
But I suddenly cannot run the CYBOL applications. Strange.
Could it be an Apple Mac issue with line ending characters?

address@hidden:/home/project/cybop/examples$ ../src/controller/cyboi 
counter/run.cybol
TEST ERROR UNKNOWN errno: 0
Could not read file. The file descriptor is null. f: 0
^C

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

So it (almost) works. Great!

> 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.

Thanks. I had a short look. Everything looks clear and proper.
But I don't want to dive into it deeper now.

> > 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.

The Debian package can be installed without errors. I tried.
But the "cyboi" executable is missing and cannot be found.
Should probably be in /usr/bin. If you like, you may have a look:
cybop/dist/deb/
cybop/dist/info/
One may see the paths used in the *.deb files. In the package,
the "cyboi" binary is in "cybop/dist/deb/cyboi-0.7.0/bin/".

The source tar.gz contains just sources.
The deb file contains compiled binaries ready to install.

However, Enrico, Debian is NOT a priority right now!
A tarball suffices. So, please deactivate Debian for now
and use the time for other important things.

> 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.

All great, but I only had a short look.
I might come back to you with questions before the next 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.

It's o.k.

> > 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?

Just use the EXACT formatting of the other entries (copy-paste).
The formatting of "ChangeLog" follows strict recommendations:
https://www.st-andrews.ac.uk/~iam/docs/tutorial.html
https://www.gnu.org/prep/standards/

One more wish:
Once everything with CMake works fine, could you please add
and describe the necessary steps in the INSTALL file?

BTW, I discovered that there are GUI tool Debian packages
for CMake, which you probably already know about:
cmake-qt-gui
cmake-curses-gui

Best regards
Christian