I'm trying to integrate cmake into a project that contains a Unity3D project. I want to bypass checks for languages, as the CMakeLists.txt file really just houses a custom command that calls Unity3D's build process. I'm aware of the LANGUAGES NONE setting in the project() command, and also a similar setting in the set_target_properties() command. However, neither seem to be working. My complete CMakeLists.txt file is pasted below:
cmake_minimum_required (VERSION 3.8)
project (
"Test-App"
VERSION
1.0
LANGUAGES
NONE
)
# For the custom command to be marked as not actually creating a file,
# you need to set the symbolic property on it
#set_property (
# SOURCE
# UNITY_OUTPUT
# PROPERTY
# SYMBOLIC
#)
add_custom_command (
OUTPUT
UNITY_OUTPUT
COMMAND
/Applications/Unity/Unity.app/Contents/MacOS/Unity -quit -batchmode -buildOSXUniversalPlayer ${CMAKE_SOURCE_DIR}/Builds/Test-Build.app
COMMENT
"Building application..."
)
add_executable (
Test-Build
UNITY_OUTPUT
)
set_target_properties (
Test-Build
PROPERTIES
LINKER_LANGUAGE
NONE
)
However, in my tereminal output cmake is still complaining that an internal variable has not been set. I get the following output:
-- Configuring done
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_NONE_LINK_EXECUTABLE
-- Generating done
-- Build files have been written to: XXX
Note that the Makefile is still generated and I can still build stuff. I simply want to get rid of this annoying error, to be sure that I fully understand how CMake is operating.
Related
My CMake build on Github Actions can't find Boost. So I enable policy CMP0074 and set variable Boost_ROOT. After that CMake finds Boost, but emits this warning:
CMake Warning (dev) at myproject/CMakeLists.txt:14 (find_package):
Policy CMP0074 is not set: find_package uses <PackageName>_ROOT
variables. Run "cmake --help-policy CMP0074" for policy details.
Use the cmake_policy command to set the policy and suppress this
warning.
Environment variable Boost_ROOT is set to:
C:\local\boost
For compatibility, CMake is ignoring the variable.
So that seems contradictory to me. Without CMP0074 it does not work. With CMP0074 it works but complains.
Details
I am trying to get a build running on Github Actions using the "windows-2022" platform which includes cmake version 3.25.1.
I have one step to install boost and another to build my code. On my first attempt, the build of my code failed because it could not find boost. So I made two changes:
I edited my CMakeLists.txt file and added this line:
cmake_policy(SET CMP0074 NEW)
I set environment variable Boost_ROOT equal to C:\local\boost (the path to which I install boost on the server).
Now, my build finds the boost header files and progresses further. (It fails at the linking stage because it can't find the boost lib files and I am working on that). But the build emits the warning mentioned above. This seems contradictory to me:
Without CMP0074/Boost_ROOT, it does not find the Boost header files
With CMP0074/Boost_ROOT, it finds the Boost header files, while also emitting a warning to say that Boost_ROOT is ignored
This makes no sense to me and I am unable to recreate the problem locally (I am running cmake version 3.25.1, same as the windows-2022 container on Github Actions.) Any idea what I'm doing wrong?
This is how my yaml file looks like so far:
name: Test
on: workflow_dispatch
jobs:
job1:
runs-on: windows-2022
steps:
- uses: actions/checkout#v3
- name: Setup MSBuild
uses: microsoft/setup-msbuild#v1.1
- name: Setup Boost
run: |
$Url = "https://boostorg.jfrog.io/artifactory/main/release/1.81.0/binaries/boost_1_81_0-msvc-14.2-64.exe"
(New-Object System.Net.WebClient).DownloadFile($Url, "$env:TEMP\boost.exe")
Start-Process -Wait -FilePath "$env:TEMP\boost.exe" "/SILENT","/SP-","/SUPPRESSMSGBOXES","/DIR=C:\local\boost"
- name: Build Myproject
env:
Boost_ROOT: C:\local\boost
run: |
Expand-Archive -Path Myproject.zip -DestinationPath C:\local
cd C:\local\Myproject
mkdir build
cd build
cmake -G "Visual Studio 17 2022" -A x64 ..
cmake --build . --config Release
With CMP0074/Boost_ROOT, it finds the Boost header files, while also emitting a warning to say that Boost_ROOT is ignored.
Actually, there is no contradiction in such behavior, because Boost headers are found via ... BOOST_ROOT variable (case insensitive!).
Details:
When a project specifies (with cmake_minimum_required) that it is written for CMake 3.11 (or older), CMake doesn't set policy CMP0074.
When such project calls find_package(Boost) and CMake observes, that environment variable Boost_ROOT is set, it emits the warning and does not add this variable implicitly to find_path and find_library calls, performed by module FindBoost.cmake.
However, the module FindBoost.cmake explicitly adds environment variable BOOST_ROOT to its find_path and find_library calls, so the directory specified by the variable is actually searched.
On Windows environment variables are case-insensitive. (Unlike to Linux variables, unlike to CMake variables). So Boost_ROOT and BOOST_ROOT are actually refer to the same variable.
There is some specific about FindBoost.cmake module: it supports (and documents!) using BOOST_ROOT environment variable as a hint for search. Such decision could look strange assuming CMake automatically adds Boost_ROOT variable to the search paths. But FindBoost.cmake has been written long before CMake 3.12 (see e.g. FindBoost documentation for CMake 3.1), so Boost developers couldn't be aware that CMake will introduce such feature at the system level.
That is, you could ignore such warning. The warning will disappear when the project migrates to CMake 3.12 or newer (as a minimum requirement).
Alternatively, instead of Boost_ROOT you could set BOOSTROOT environment variable as a hint: such variable is not checked by CMake itself, but used in FindBoost.cmake module.
I've downloaded the binaries: or-tools_VisualStudio2022-64bit_v9.3.10497
I'm using vs2022 on win10. My shell has cygwin in the path if it's related.
I ran
%comspec% /k "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat"
cl.exe is in the path, and which.exe finds it.
I ran make test_cc, but it complained
the cl command was not found in your PATH
exit 127
make: *** [Makefile:271: test_cc] Error 127
The var CXX_BIN was empty even though which cl returned the correct path. I set it manually to cl.
Then, there was a complaint about echo and a newline, which I commented out. Then, it couldn't find md, so I created manually md objs.
A few of the examples were built, but then it stopped with another error. For now, I just got what I want:
make run SOURCE=examples/cpp/solve.cc
but probably there was an easier way to get it?
I tried to build it from the source using cmake. Doesn't work off-the-shelf as well:
Build abseil-cpp: OFF
...
CMake Error at C:/prj-external-libs/vcpkg/scripts/buildsystems/vcpkg.cmake:824 (_find_package):
By not providing "Findabsl.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "absl", but
CMake did not find one.
Could not find a package configuration file provided by "absl" with any of
the following names:
abslConfig.cmake
absl-config.cmake
Add the installation prefix of "absl" to CMAKE_PREFIX_PATH or set
"absl_DIR" to a directory containing one of the above files. If "absl"
provides a separate development package or SDK, be sure it has been
installed.
Call Stack (most recent call first):
cmake/deps.cmake:33 (find_package)
CMakeLists.txt:304 (include)
If finds gurobi95.dll, but it can't find the function GRBtunemodeladv.
On failure, solve.exe crashes with (unknown) names in the stack trace. Need to add debug symbols and graceful error handling.
cmake looks more promising, and I was missing dependencies. Should give it a flag -DBUILD_DEPS:BOOL=ON.
OR-Tools depends on few external dependencies so CMake build will try to find them using the idiomatic find_package() => your distro/env(vcpkg ?) must provide them, just regular CMake stuff here.
ref: https://cmake.org/cmake/help/latest/command/find_package.html
note: we provide few findFoo.cmake here https://github.com/google/or-tools/tree/main/cmake
We also provide a meta option to build statically all our dependencies, simply pass -DBUILD_DEPS=ON cmake option at configure time.
You can also build only some of them, please take a look at
https://github.com/google/or-tools/tree/main/cmake#dependencies
Concerning Gurobi and GRBtunemodeladv symbol, this one has been removed by last version of Gurobi so we fix it in v9.4/main/stable branch...
see: https://github.com/google/or-tools/commit/d6e0feb8ae96368523deb99fe4318d32e80e8145
My developer friend who has the luxury of developing in a non-Windows environment has been raving about Compass. I finally decided I wanted to give it a try. I'm tired of trying to keep up with all of the intricacies of cross-browser CSS.
So, I found it on NuGet, and installed it.
I installs to my solutions root directory in the packages directory:
$(SolutionDir)packages\Ruby.Compass.0.12.2.3\
It comes with a Readme that states the following message:
Ruby Compass v. 0.12.2
Compass is installed in its own NuGet package dir, and available by
'compass' command in "packages\Ruby.Compass.0.12.2.3" folder.
To compile Compass files during build, add the next line to the
project pre-build events:
"$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile
"$(ProjectDir)."
So, I placed the line in my pre-build events, saved, and tried to build my project. However, I get an error as follows:
The command
""$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile "$(ProjectDir)."" exited with code 1.
Notice: It actually shows the full path to the ProjectDir and SolutionDir as it's supposed too in the error message. I replaced them with the tokens to keep the project name unanimous.
Let me mention that I tried variations of the suggestion pre-build line:
"$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile "$(ProjectDir)"
"$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile "$(ProjectDir)css"
"$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile "$(ProjectDir)css\test.scss"
The first one just removed that trailing .. The second one pointed it to the directory where all my css files are stored. The third one pointed it to the exact file I was trying to compile was located.
I opened up compass.cmd which is the file it is calling, and it looks like the following:
#echo off
"%~dp0ruby\bin\compass" %*
I'm assuming this calls the compass file in the ruby/bin folder, which looks like this:
#!C:/downloads/ruby-2.0.0-p247-x64-mingw32/ruby-2.0.0-p247-x64-mingw32/bin/ruby.exe
#
# This file was generated by RubyGems.
#
# The application 'compass' is installed as part of a gem, and
# this file is here to facilitate running it.
#
require 'rubygems'
version = ">= 0"
if ARGV.first
str = ARGV.first
str = str.dup.force_encoding("BINARY") if str.respond_to? :force_encoding
if str =~ /\A_(.*)_\z/
version = $1
ARGV.shift
end
end
gem 'compass', version
load Gem.bin_path('compass', 'compass', version)
From there, I'm not sure what is going on. I'm not a Ruby person.
Is there an issue that I'm overlooking here?
Has anyone else been able to install Ruby.Compass via NuGet?
How can I get this working in Visual Studio without having to fight with Ruby?
From: http://codewith.us/automating-css-generation-in-visual-studio-using-sasscompass/
"Note that, if there are issues with your SCSS files, you will receive some variation of the error below.
Error 36 The command "del "C:Projectspubliccss*.css" /S
compass compile "C:Projectspublic" --force" exited with code 1.
Open your Output window (click View -> Output or press Ctrl+W, O), and select “Build” in the “Show output from:” menu. Scroll up until you find your command in the log and you should get a little more insight into what portion of the command failed."
Something like this:
cmake --get-variable=MY_CMAKE_VARIABLE
The variable may exist in an included CMake file.
If you have an existing cache file, you can do:
grep MY_CMAKE_VARIABLE CMakeCache.txt
If you do not yet have a cache file and you want to see what options there are in a CMakeLists.txt file, you can do (in a different directory since this will write a cache file):
cmake -L /path/to/CMakeLists.txt | grep MY_CMAKE_VARIABLE
which will return to you something like
<VARIABLE>:<TYPE>=<VALUE>
If it is an advanced variable, add the -A flag to the same command and it will include advanced variables. Of course, if you only want the value, you can do:
cmake -L /path/to/CMakeLists.txt | grep MY_CMAKE_VARIABLE | cut -d "=" -f2
EDIT
For example, with a CMakeLists.txt that is:
cmake_minimum_required(VERSION 2.8)
project(test)
include(otherFile.txt)
set(MY_VAR "Testing" CACHE STRING "")
And where otherFile.txt is:
set(MY_OTHER_VAR "Hi" CACHE STRING "")
The command (run from another directory):
cmake -L ../cmaketest
Gives:
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/tgallagher/cmaketest-build
-- Cache values
CMAKE_BUILD_TYPE:STRING=
CMAKE_INSTALL_PREFIX:PATH=/usr/local
MY_OTHER_VAR:STRING=Hi
MY_VAR:STRING=Testing
So, it does show variables from other files. It should parse the entire build. The issue though is that it will not show any variables that are not marked with CACHE. And it will not show any that are cached INTERNAL, and will only show ADVANCED if -LA is used instead of -L.
If your variables are marked as INTERNAL or not CACHE'd at all, then there is no method within CMake to pull it out. But, non-CACHE'd variables are meant to be transient, so I'm not sure why you would need them outside of a build environment anyway.
Use:
cmake -LA -N /path/to/project
to get a listing of all cache values. The -N is important; it prevents cmake from trying to generate any build files, and just shows you what's in the cache.
If the variable you want is not something you're setting, but something from the defaults, you can use
cmake --system-information
And grep that. Note it does seem to take a second or two which seems kinda slow.
If for example you're trying to do this to configure your cmake vars in the first place, it avoids getting the cart out in front of the horse. :)
You can also pass this a file name. So you can try only generating it if it doesn't exist, and parse the file if it does (to save that 1-2 seconds).
If you need get non cached user variable but can't edit original cmake script, you may resort to a trick. Create new CMakeLists.txt file in another directory with the following content:
include(<Path to original CMakeLists.txt>)
message(STATUS "MY_VAR={${MY_VAR}}")
It is quite possible, cmake will made a lot of errors while running in new directory. Relative paths, if used in original script, is definitely a cause for such errors. But cmake will print last value assigned for your variable. Further, filter all errors and warnings using any well known text processor (assume UNIX familiar), for example:
cmake . | sed -n 's/-- MY_VAR={\(.*\)}/\1/p' 2>&1
I use this approach in projects maintenance scripts, it is reliably as long as original CMakeLists.txt has no syntax errors.
-D <var>:<type>=<value>:
When cmake is first run in an empty build tree, it creates a CMakeCache.txt file and populates it with customizable settings for the project. This option may be used to specify a setting that takes priority over the project's default value. The option may be repeated for as many cache entries as desired.
I have different behaviour of compiler, when building project from IDE and from command-line, which I can not explain.
The detailed issue's description is rather big, but it's really simple.
I have a C++ Builder project, which has a PAS-file included (IncludeUnits.pas). This pas-file has several units and inc-files listed. These files are located in separate folders and these folders are listed in library&include paths in project's options.
Folders layout:
C:\Demo\Bin
C:\Demo\Project
C:\Demo\Project\CBuilder5
C:\Demo\Project\Common
C:\Demo\Source
C:\Demo\Source\Common
Bin is output folder, Project/CBuilder5 holds project (bpr-file), Project/Common holds included pas-file (IncludeUnits.pas), Source and Source/Common hold other files (pas&inc). I think that it's pretty usual layout.
C:\Demo\Project\Common\ IncludeUnits.pas :
unit IncludeUnits;
interface
uses
Test;
implementation
end.
C:\Demo\Source\ Test.pas :
unit Test;
interface
{$I Test.inc}
implementation
end.
C:\Demo\Source\Common\ Test.inc :
// this file is empty
If I compile this project from C++ Builder IDE - it will compile fine. C++ Builder IDE doesn't have any additional paths in IDE settings set.
Now, I want to compile it from command-line. First, I issue
bpr2mak.exe MyProject.bpr
command.
This command creates MyProject.mak file, where I can see all paths ("....\Source" and "....\Source\Common" are the paths in question):
...
INCLUDEPATH = $(BCB)\include;$(BCB)\include\vcl;..\Common;..\..\Source;..\..\Source\Common
LIBPATH = $(BCB)\lib\obj;$(BCB)\lib;..\Common;..\..\Source;..\..\Source\Common
...
Now, I run make command:
make.exe -B -f"MyProject.mak"
It gives me the following output:
C:\PROGRA~1\Borland\CBUILD~2\BIN\dcc32 -N2....\Bin -N0....\Bin -$Y+ -$W -$R -v -JPHNE -M -UC:\PROGRA~1\Borland\CBUILD~2\bin..\include;C:\PROGRA~1\Borland\CBUILD~2\bin..\include\vcl;..\Common;..\..\Source;..\..\Source\Common -D_DEBUG;_RTLDLL;NO_STRICT -OC:\PROGRA~1\Borland\CBUILD~2\bin..\include;C:\PROGRA~1\Borland\CBUILD~2\bin..\include\vcl;..\Common;..\..\Source;..\..\Source\Common --BCB ..\Common\IncludeUnits.PAS
Borland Delphi Version 13.0 Copyright (c) 1983,99 Inprise Corporation
C:\Demo\Project\Common\IncludeUnits.pas(1) C:\Demo\Project\Common\IncludeUnits.pas(1) C:\Demo\Project\Common\IncludeUnits.pas(1) C:\Demo\Project\Common\IncludeUnits.pas(6) C:\Demo\Source\Test.pas(1) C:\Demo\Source\Test.pas(5) Fatal: File not found: 'Test.inc'
As you can see - all search path is passed to compiler and the file (Test.inc) is all here - in that Source\Common folder. But still compiler can't find it?
Of course, I run both commands from folder with bpr-file. And changing paths to absolute doesn't help.
Copying Test.inc from Source\Common to Source will help. Changing {$I Test.inc} to {$I Common\Test.inc} will also help.
Why? It seems that I'm missing something. Remember: project have no problems with compiling from IDE, Test.inc is found without copying or changing declaration. Did I miss some switch to make or dcc32?
I found the reason: command line for dcc32 misses -I switch, which specifies paths for include files.
For some reason, bpr2mak doesn't respect this option. Fortunately, it allows you to specify alternate template for conversion bpr -> mak. I edited default template and added "-I" option to it, pass new template to bpr2mak - and it worked.