Run generated makefile without CMake installed - makefile

I want to compile my program on our university HCP server, I created it as a CMake project on my laptop but the server does not have CMake installed and I can not install it (limited storage).
How do I compile the project on the server without CMake and only make?
I ran cmake command on my laptop and then transferred the sources and generated Makfile to the server, but when I execute make on the server it complains about cmake missing:
make: /usr/local/bin/cmake: Command not found
make: *** [cmake_check_build_system] Error 127
Is it possible to generate a Makefile that can run only make and does not need CMake installed?

This is not possible, for two major reasons:
As pointed out in the comments, the generated Makefiles will again attempt to call CMake during the build.
Besides that, Makefiles generated by CMake are not supposed to be portable. A Makefile generated on one machine is likely to break when copied to another.
Note that CMake has no mandatory external dependencies, so you should be able to quickly build a local copy from source on the server and use that to build your project. If that is for whatever reason not feasible, you cannot use CMake and will have to rely on a different method for building, like writing your own ad-hoc Makefile from scratch.

Related

no pdcures.dll created when using make -f Makefile for win 10 pdcurses

I have been trying to install PDcurses on my Windows 10 machine. The README.md says to run: make -f Makefile to build pdcures.dll in the 'wincon' folder. However when i ran this in Powershell it did not create any .dll, instead creating many .o files.
Then i tried to run 'make -f Makefile.wcc' in Powershell and it returned the error 'makefile.wcc:9: *** missing separator. Stop.' I got similar errors using Makefile.bcc and Makefile.vc.
What am i doing wrong here? Am i supposed to build one of the .c files?
Each of the Makefiles is compiler-specific, as described in the README.md. There's no reason to try Makefiles intended for compilers other than the one you're using.
The Makefile doesn't build a DLL, by default -- only a static library (ending in .a or .lib). PDCurses is a small library, and there's not much benefit in building it as a DLL. But if you want to, that procedure is also described in the README.md. In short:
make DLL=Y
but please read the file for details. Note that, even if you build PDCurses as a DLL, you'll still also need the .a or .lib file to link against.

Shared library under Windows and CMake: DLL not found before installation

The library mylib consists of the library proper, in directory lib/, and a test suite, in directory test/. It is completely under CMake control:
mylib/CMakeLists.txt:
...
add_subdirectory(lib)
add_subdirectory(test)
...
mylib/lib/CMakeLists.txt:
...
add_library(my_lib ${src_files})
...
mylib/test/CMakeLists.txt:
...
add_executable(mytest mytest.c)
target_link_libraries(mytest mylib)
Build steps are:
mkdir build
cd build
cmake ..
make
ctest # or make test
make install
Works under Linux, stable since many years. Under Windows10 though, a message window pops up, entitled "mytest.exe - System error": "The code execution cannot proceed because mylib.dll was not found. Reinstalling the program may fix this problem."
No, installing (rather than reinstalling) would not be a good solution: I need to first test the library before I install it (btw: this excludes most solutions proposed in response to somewhat similar questions).
Isn't CMake supposed to work cross-platform? What is the minimally invasive adjustment to make the above build steps work under Windows?
The right way of doing this on Windows is to populate the PATH environment variable for the test run:
set_tests_properties(your_test_name
PROPERTIES
ENVIRONMENT PATH="path-containing-your-dll")
I believe you can use generator expression if path-containing-your-dll is a function of an artifact that you generate in your build.
Cherry on top: since cmake 3.13, the variable VS_DEBUGGER_ENVIRONMENT can also be set on the target for having a nice debugging behaviour inside Visual Studio (eg. being able to debug the application directly from Visual instead of going through ctest).

Why do I do Cmake .. and make?

I'm trying to install some programme on an Amazon Linux 2 distribution and for some reason, I've to compile a bunch of tools from source.
It was my understanding I should do:
cd my_source_code
./configure
make
make install
The intent would be:
./configure will check if I have all tools needed
make: will compile the source files into binaries that I can then use
make install: will place that said binaries in an accessible place
All of that tools ask me to do different stuff, for example:
./bootstrap
make
make install
or
./bootstrap.sh
./b2
./b2 install
or
cmake .
make
make install
I guess the ./boostrap is just the ./configure script with a different name. Is that right?
For the cmake, why do I have to do both cmake and make? Aren't they the same?
I a bit lost with all that possibilities.
Yes, cmake . is a configuration step and corresponds to ./configure from Autotools. In result of running this command you get whatever build files you have requested - Makefiles of various sorts, Visual Studio projects, etc.
After that you need to actually build them. In case of Makefiles you run make and in case of Visual Studio you open it in the IDE and click "Build" (or run msbuild, if you want console).
CMake has --build flag to automatically invoke underlying build system, so you can also do
# configure
cmake .
# build
cmake --build .
CMake is equivalent to running ./configure but is autoconf and automake combined into a single program. It is automake which generates the Makefiles. CMake started on Windows and can not only generate Unix Makefiles but also Visual Studio projects and some other targets.
Make is very low level and doesn't directly support a recursive build that traverses a directory structure. CMake and Automake are Makefile generators that provide a higher level of abstraction and provide a mechanism to create a recursive build.
./bootstrap in general has the steps to create the configure script which is usually not in the git repo because it is generated. When a source tarball is created the configure script is included for convenience.

How to distribute gcc compiler binaries?

I want to distribute a gcc compiler within our company. I built required version from the sources, installed it in specified directory on my machine (all machines, btw, have the same architecture). I expected that I can put contents of this directory on the server and with the next update all my colleagues will get a new compiler.
But of course that doesn't work.
I tried to search for a ready solution for the linux but couldn't find anything.
Right now if I try to compile some basic program I get an error:
gcc: error trying to exec 'cc1plus': execvp: No such file or directory.
But this file was build and indeed resides in one of the subfolders of main install directory. I tried to explicitly specify the path to this subprogramm using GCC_EXEC_PREFIX and COMPILER_PATH environment variables but with no luck.
Is it possible to achieve what I want?

Compile Boost on WIndows XP

I am trying to compile the Boost library for Windows (as a prerequisite for building the Bitcoin client), using the MinGW compiler toolchain to do so (rather than Visual Studio) and running into errors.
Following various guides online, I have a working bjam application, and the boost_1_55_0 source files. I have tried in the windows shell doing:
path/to/bjam.exe toolset=gcc --build-type=complete stage (the instructions that Bitcoin provides), but get mingw.jam: No such file or directory errors
bootstrap mingw from a standard DOS shell runs successfully, but the .\b2 after emits a bunch of 'cl' is not recognized as an internal or external command, operable program or batch file errors, implying it's not really set up to use gcc/mingw, since it's calling for the Microsoft compiler.
bootstrap.sh --with-toolset=mingw from the MSYS prompt (as suggested here, which creates a log file that doesn't have as many errors, but running ./b2 after leads to a mingw.jam no such file error, and mingw.init unknown error.
Downloading the compiled binaries from http://sourceforge.net/projects/boost/files/boost-binaries/1.55.0/ (boost_1_55_0-msvc-12.0-64.exe). After extracting and referring to the lib and header files, compiling the final executable throws a whole bunch of undefined reference to 'boost::system::generic_category()' for various boost features, implying to me the library files aren't actually containing the proper definitions? Is that because they're Visual Studio libraries?
Downloading the archives from http://www.boost.org/users/history/version_1_55_0.html (boost_1_55_0.7z), which the documentation implies comes with a pre-compiled lib dir, but does not in fact.
So, I'm banging my head on several walls at once. Can anyone help me get past any of these roadblocks?
I used the following steps to successfully build boost version 1.54 in a MinGW/MSYS environment:
Build bjam.exe and b2.exe:
boost_1_54_0\tools\build\v2\engine>build.bat mingw
Copy build tools to the root-directory:
cp boost_1_54_0\tools\build\v2\engine\bin.ntx86\*.exe boost_1_54_0
Run bjam.exe:
bjam --toolset=gcc --build -type=complete install > boost_build.log
I used this process with slight variations for various boost versions, so its a good guess it will work for 1.55 too

Resources