#890 2.1.0 RC1 does not work with cmake 3.0.0

[Kristof]

Just tried to test the RC1 under Arch Linux with cmake 3.0.0, and it gave a ton of warning, and finally an error complaining about -lpthreads. The cmake output files are attached.

Can anyone fix it quickly? If not, then at least INSTALL.txt must be updated to explicitly say that cmake 3 is unsupported.

[Kristof]

Forgot to add, that about 2 weeks (with cmake 2.8) I could build the svn successfully, so it is likely not a missing dependency. /usr/lib/libpthread.so and /usr/lib/libpthread.a are also present.

[madbad]

Build fine for me (with a lot of warnings) in Fedora 21 cmake v. 3.0.0

[madbadnew@localhost ~]$ cmake -version

cmake version 3.0.0

[Kristof]

Ok, the problem is not with cmake 3, it does not work for me on Debian (cmake 2.8.9), too. Even worse, it does not work on recent svn (r5781). Is there a new option I am supposed to use?

I will try to find the problematic file and revision.

[Kristof]

The problem seems to be in r5767, in cmake/install.cmake. When reverting it to the previous version (r5660) in svn, cmake can generate makefiles again.

[beaglejoe]

Sorry, I don't think that I meant to commit that file.

[beaglejoe]

Reverted install.cmake to [r5660]

[Kristof]

Thanks, now svn builds again. However, after extracting src-base package and replacing install.cmake I still get the same error about -lpthreads. Strange, I will continue examining it tomorrow.

[simon wood]

Can you please clarify when you are getting the message about '-lpthreads'.

When I said the src tars work on Linux, I did not do a native "$ make install", but rather to a special directory and had Desura client app handled dependencies.

[simon wood]

maybe want something like:
https://github.com/skogler/glc/commit/ab18b114b9fdc6c67564b94db2ec95fda6589765

in:
https://sourceforge.net/p/speed-dreams/code/HEAD/tree/trunk/cmake/thirdpartydeps.cmake

[Kristof]

So it seems even SVN does not work now.

For the messages see the end of the attached log files. Basically after it says:
Determining if the function pthread_create exists in the pthread passed with the following output:

I have /usr/include/pthread.h with pthread_create in it.

Something interesting: CMakeOutput.log has -lpthread at the end of the cc command line, while CMakeError.log complains with a line ending -lpthreads. (Beware the ending s) I think -lpthread is the correct option, but why does it change?

[Kristof]

I was wrong, svn still works, sorry for the confusion.

More important, I think those -lpthreads errors in the log file are how cmake normally works (searchs for -lpthreads, which errors, then for -lpthread, which it finds).

But ccmake gave me the following error message (when using the base source file):
CMake Error at src/tools/CMakeLists.txt:10 (ADD_SUBDIRECTORY):
add_subdirectory given source "menuview" which is not an existing
directory.

If OPTION_OFFICIAL_ONLY is set to true, it works! So either we should
- make this the default (not a bad idea in a release, I guess)
- remove the lines about menuview in the source package.

[simon wood]

In the 'release the source' process, I am changing (un-commenting) this line.
https://sourceforge.net/p/speed-dreams/code/HEAD/tree/trunk/CMakeLists.txt#l19

If you follow it with "SET(OPTION_OFFICIAL_ONLY On)" (or something like that), does this solve your build problem?

This would be a quick way to ensure that only the official stuff got built from out-of-SVN sources, and keeps 'special' changes localized.

[beaglejoe]

If we want to change the default CMake options, I suggest doing it in options.cmake:
https://sourceforge.net/p/speed-dreams/code/HEAD/tree/trunk/cmake/options.cmake#l63
https://sourceforge.net/p/speed-dreams/code/HEAD/tree/trunk/cmake/options.cmake#l94
This is where all the option defaults are set.
IMO:
OPTION_AUTOVERSION should be OFF:
1. Users untarring to a random directory and building won't get 'unversioned'
2. If/when we move to git, their versioning scheme contains no useful information.

IMO:
OPTION_OFFICIAL_ONLY should be ON:
Building the 'unofficial' content is more of an advanced task.

My 2 cents.

[beaglejoe]

Now that this has been tracked down, It seems to be a duplicate of [#684]

[Kristof]

Looking once again, the root of the problem is that src/tools/CMakeLists.txt uses ADD_SUBDIRECTORY instead of SD_ADD_SUBDIRECTORY. The difference is that SD_ADD_SUBDIRECTORY does not cause error when the subdirectory is missing, only a warning. It seems ADD_SUBDIRECTORY is only used for essential subdirectories, when a missing one is really an error.

For this problem I think the best solution is using SD_ADD_SUBDIRECTORY(menuview), this way cmake will not error, even when someone experiments with building non-official tasks.

I also agree with setting OPTION_OFFICIAL_ONLY to ON, and OPTION_AUTOVERSION to OFF by default for the source packages, probably only in the 2.1.0-rc1 tag.

I think [#684] is not exactly a duplicate, only a similar problem. Hopefully setting OPTION_OFFICIAL_ONLY to ON will solve that one, too.

[Kristof]

Fixed CMakeLists.txt was committed in [r5784] for trunk. Joe, I will let RC tags as your "playground", copy the fix as you see appropriate.

[beaglejoe]

I think [#684] is not exactly a duplicate, only a similar problem. Hopefully setting OPTION_OFFICIAL_ONLY to ON will solve that one, too.

You are correct. Duplicate was the wrong word. I meant that this should fix [#684]

[simon wood]

Can we close this ticket out, leaving the outstanding problem to be fixed in #684?

[Kristof]

The fix was committed, and copied to the RC tag, so this is fixed now.