2

I'm trying to follow these instructions to compile-install BASIS (CMake Build system And Software Implementation Standard) on MSYS2 using MinGW-w64 compilers. However, the ccmake .. step fails:

-bash: ccmake: command not found

I tried searching the MSYS2 packages by pacman -Ss ccmake with no results. So I thought I have to use commandline cmake instead:

cmake -DCMAKE_INSTALL_PREFIX:PATH=~/local -DBUILD_APPLICATIONS:BOOL=ON -DBUILD_EXAMPLE:BOOL=ON ..

which failed by:

CMake Error at src/cmake/modules/ProjectTools.cmake:876 (message):
  CMAKE_INSTALL_PREFIX must be an absolute path!
Call Stack (most recent call first):
  src/cmake/modules/ProjectTools.cmake:2525 (basis_installtree_asserts)
  src/cmake/modules/ProjectTools.cmake:2751 (basis_project_begin)
  CMakeLists.txt:69 (basis_project_impl)

as a workaround I changed the ~/local to /home/<userName>/local which seem to be working. However, I don't know where the MakeFile(s) are, cause when running the make . I get the error:

mingw32-make: *** No targets specified and no makefile found. Stop.

given that I have alias make='mingw32-make in the ~/.bashrc file. I would appreciate if you could help me know what is the problem and how I can solve it. I have the MSYS2-MinGW-w64 package mingw64/mingw-w64-x86_64-cmake installed. My Windows is version 1909, and MSYS_NT-10.0-18363 is my environment.

P.S.1. Looking at the CMake's output I now see that there is actually a warning:

CMake Warning (dev) in CMakeLists.txt:
  No project() command is present.  The top-level CMakeLists.txt file must
  contain a literal, direct call to the project() command.  Add a line of
  code such as

    project(ProjectName)

  near the top of the file, but after cmake_minimum_required().

  CMake is pretending there is a "project(Project)" command on the first
  line.
This warning is for project developers.  Use -Wno-dev to suppress it.

which is a bit ironic for this project, but I am not sure if this is the reason why the compiling fails.

P.S.2. I had the mingw64/mingw-w64-x86_64-cmake package installed, which doesn't have the ccmake tool. But the msys/cmake does. So:

  • pacman -R mingw-w64-x86_64-cmake
  • pacman -S msys/cmake

now ccmake is available.

Foad S. Farimani
  • 12,396
  • 15
  • 78
  • 193
  • The Makefiles should be located in the *same* directory that you ran `cmake`, so you should just be able to run `make all`. – Kevin Mar 18 '20 at 21:30
  • @squareskittles tried that too, doesn't work. Is there anything wrong with my CMake command? cause it finishes with no error or warning! – Foad S. Farimani Mar 18 '20 at 21:42
  • CMake does not handle the `~` well in paths, so you should delete the build folder, and re-run CMake using the **full** path. – Kevin Mar 18 '20 at 21:46
  • @squareskittles nope! didn't help either. – Foad S. Farimani Mar 18 '20 at 22:01
  • 1
    If the last line of CMake output is "Build files have been written to ..." then CMake configuration completes successfully and given directory contains the configured project. But dependent on CMake settings, CMake may configure projects for different build systems. If build directory doesn't contain `Makefile`, then the project has been configured for other build system. You may explicitely specify build system ([generator](https://cmake.org/cmake/help/v3.9/manual/cmake-generators.7.html)) using `-G` parameter. – Tsyvarev Mar 18 '20 at 22:17
  • @Tsyvarev this should be it. I have `Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27038 for x86` installed at `C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe` which one of those generators should I use? – Foad S. Farimani Mar 18 '20 at 22:19
  • 1
    For build with `make` under MSys use `MSYS Makefiles` generator. – Tsyvarev Mar 18 '20 at 22:22
  • @Tsyvarev I used the command `cmake -DCMAKE_INSTALL_PREFIX:PATH=/home/fsfar/local -DBUILD_APPLICATIONS:BOOL=ON -DBUILD_EXAMPLE:BOOL=ON -DCMAKE_MAKE_PROGRAM=mingw32-make.exe .. -G "MSYS Makefiles"` but it fails at compiling now! – Foad S. Farimani Mar 18 '20 at 22:26
  • solved the first compiling error from [here](https://github.com/google/googletest/issues/606#issuecomment-229791671) – Foad S. Farimani Mar 18 '20 at 22:38
  • I now get `undefined reference to `_dupenv_s'` errors at compile time. looking at [here](https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/dupenv-s-wdupenv-s?view=vs-2019) for a solution. – Foad S. Farimani Mar 18 '20 at 22:56
  • Now trying the `cmake -DCMAKE_INSTALL_PREFIX:PATH=/home/fsfar/local -DBUILD_APPLICATIONS:BOOL=ON -DBUILD_EXAMPLE:BOOL=ON .. -G "Visual Studio 15 2017 Win64"` CMake command instead. – Foad S. Farimani Mar 18 '20 at 23:11
  • The above CMake command finishes with `Build files have been written to...` but there are no MakeFile(s)! – Foad S. Farimani Mar 18 '20 at 23:32
  • 1
    `pacman -S cmake` should install it and `which ccmake` should yeild `/usr/bin/ccmake` – Gerhard Mar 19 '20 at 07:23
  • @Gerhard isn't there a specific package which installs `ccmake`? I don't like MYS2 package bundles. – Foad S. Farimani Mar 19 '20 at 11:02
  • 1
    @Foad It is installed for me as part of cmake. – Gerhard Mar 19 '20 at 14:34
  • 1
    Re: need for "project()" command in top-level CMakeLists, this is a known "issue" introduced in more recent CMake versions (since when BASIS was created). See also https://github.com/cmake-basis/BASIS/issues/629 for reference. – Andreas Schuh Mar 22 '20 at 19:18

1 Answers1

1

OK, I think I found a temporary workaround by using the MSVC compilers:

  • cmake -DCMAKE_INSTALL_PREFIX:PATH=/home/<userName>/local -DBUILD_APPLICATIONS:BOOL=ON -DBUILD_EXAMPLE:BOOL=ON .. -G "Visual Studio 15 2017 Win64"
  • cmake --build . --config release --target install
  • the executable is ~/local/Bin/basisproject.cmd which has a bizzare file extention but seem to be working!
Foad S. Farimani
  • 12,396
  • 15
  • 78
  • 193
  • 1
    Thanks for the details. Regarding the `.cmd` extension, it denotes the file as Windows Command script. It is just a text file, and you can have a look in the text editor to see what it does. In this case, it should be a wrapper around Python. It's a trick to make a Python script executable on Windows without having to explicitly invoke the Python interpreter. Unlike Unix, Windows has no "she-bang". By wrapping a Python script within a Windows Command which class the configured Python interpreter, you can treat `basisproject` as you would treat compiled executable binaries. – Andreas Schuh Mar 22 '20 at 19:23