Re: [cybop-developers] CMake

[Christian Heller]

Hi Enrico,

> first of all it’s really fun to participate on cybop after such a long time.
> There is a small gap of time i can use at the moment to support the project a 
> little bit, so i’m eager to help to improve with the project as good as i can.

yes, the pleasure is on my side. Thanks for this.
Feel free to add your name as author to any file you touched.
At least you should get some credits for contributing to the project.

> > I then received two compile errors which I could fix in CYBOI.
> > See the following email "CMake Errors”.
> Interesting that the compile errors didn’t occur using the makefiles and 
> additional that they did not happen on my machine.

Yes. They didn't appear either when using the autotools.

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


Perhaps you could remove these (and other) unnecessary dependencies?

> > When packaging CYBOP for distribution with CPack, you may want to also
> > consider the files in directory: admin/ There are e.g. three man pages:
> > cyboi.1.gz
> > cybol.5.gz
> > cybop.7.gz
> I haven’t found a way to include the manpages in the cpack process yet. But i 
> think some people have been able to already by using some custom commands.
> BTW the manpages are not up to date and still contain berlios pages. I will 
> create an issue for updating the manages.

O.k. I updated them and closed the bug.

> > and a CYBOP icon in various sizes, that might get mentioned in CMake
> normally icons are provided using .ico file extension.
> There is a command for .ico and there is also the opportunity to define a 
> windows icon using a png.

Yes, the CYBOP icons are there in *.png format.

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

> > 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
and other formats.

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

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

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.

Regards
Christian