I've compiled a K definition using kompile foo.k.
However, when I run krun --directory foo-kompiled/ my-program.foo I see the following error:
[Error] Critical: Could not find a compiled definition. Use --directory to specify one.
How do I correctly use this option?
For historical reasons, kompile --directory . foo.k creates a directory foo-kompiled underneath . rather than using . as the output directory itself. Similarly, krun and other tools that use a compiled k definition look for a directory matching the glob *-kompiled within the directory passed by --directory. Thus, if you run kompile foo.k the correct invocation for krun (since the default value of --directory is the current working directory) is krun my-program.foo --directory ., or simply krun my-program.foo
Related
I'm trying to create a Singularity image for some application software that normally builds into a single directory. To use after building, you source a setup file "env.sh" that sets a bunch of environment variables including modifying PATH and LD_LIBRARY_PATH.
If my recipe looks like this:
Bootstrap: docker
From: ubuntu:20.04
%files
/path/to/myapp /opt/myapp
%post
cd /opt/myapp && make
%environment
. /opt/myapp/env.sh
so that env.sh is sourced automatically on launching the image, I get the following error:
Singularity runtime parent: relocation error: /lib/x86_64-linux-gnu/libnss_files.so.2: symbol __libc_readline_unlocked, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
However, if I remove the %environment section from the recipe, then manually call . /opt/myapp/env.sh after invoking singularity shell, everything works as expected.
Given that the environment script is not doing anything other than setting some environment variables, why am I getting this error?
obj-m := $(MODNAME).o
ccflags-y := $(CCFLAGS)
src_files := $(wildcard $(foreach pat,*.c *.cpp *.s,src/$(pat) src/$(MODNAME)/$(pat)))
$(MODNAME)-objs := $(addsuffix .o, $(basename $(src_files)))
all:
make -C $(KDIR) M=$(shell pwd) modules
clean:
make -C $(KDIR) M=$(shell pwd) clean
I have this make file for building kernel modules. However whenever I run it, I get an error saying that there is no rule to make target .c. .c is not a source file. If I remove the "if [ -d src ]" check then I get an error saying src doesn't exists on the recursive make call from the kernel build system. If I specify the full path to src it gives the same output saying that it can't find it (which is really weird). If I hard code src_files it works (if I didn't copy and paste wrong). Does anybody have any idea what is going on?
In your makefile you expect current directory to be the one contained given makefile. But when your file is executed from Kbuild context, this is no longer true: current directory is directory with kernel sources.
That is why content of src_files variable becomes wrong: wildcard cannot find files under src/ in kernel sources. You may use special src variable for refer to directory with your makefile:
src_files := $(wildcard $(foreach pat,*.c *.cpp *.s,$(src)/src/$(pat) $(src)/src/$(MODNAME)/$(pat)))
From the other side, paths enumerated in *-objs variable should be relative (this is requirement by Kbuild). So you need to strip prefix from these absolute paths:
src_files_rel := $(src_files:$(src)/%=%)
Then you may use these paths for create objects list:
$(MODNAME)-objs := $(addsuffix .o, $(basename $(src_files_rel)))
Describe difference between these two command lines:
C:\xxxxx> cmake -help
Usage
$ cmake [options] <path-to-source>
$ cmake [options] <path-to-existing-build>
Specify a source directory to (re-)generate a build system for it in the
current working directory. Specify an existing build directory to
re-generate its build system.
The last description does not give me how to use the first, or the second.
Could you explain it to me?
When you use you do an in-tree build (cmake .), there is no difference.
When you do an out-of-tree build, there is a difference.
Suppose your project lives in ~/foo and your current directory is ~/foo/build
You have to run cmake .. for the first build. But for subsequent reconfigures, you can use cmake . because there is already a build there.
This command:
cmake [options] <path>
works as follows:
if <path> is not a valid (that is, already configured) CMake build directory, it is assumed to contain a CMakeList.txt. CMake will configure the current working directory as a build directory using <path>/CMakeLists.txt for source directory.
if <path> is a valid CMake build directory, the command reconfigures that directory using the source directory assigned when you first configured that build directory
So the common usage patterns are:
initial configuration:
mkdir my-build-dir
cd my-build-dir
cmake [options] my-source-dir
subsequent (re)configurations:
cmake [options] my-build-dir # current-work-dir is not important
alternative (initial) configuration using undocumented options:
cmake -Hmy-source-dir -Bmy-build-dir [options] # cwd is not important
I would like to run configure_file() whose input file is generated using add_custom_command, through a custom dependency, before installing the output of configure_file.
I'm in reality using a ruby script to read a cmake formatted file, to extract
a few definitions which i can convert to Ruby constants in a separate library. Thus, i require the configure_file such that cmake can replace its internal variables in the ruby generated file, whose goal is to export these variables.
Thus far, I've attempted the following:
# Custom command to build the out.rb.in
add_custom_command (
OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/output.rb.in"
COMMAND ruby ${CMAKE_CURRENT_SOURCE_DIR}/build_ruby_output.rb
-i ${CMAKE_CURRENT_SOURCE_DIR}/input.cmake
-o ${CMAKE_CURRENT_BINARY_DIR}/output.rb.in
)
# Custom target is required to build it
add_custom_target (
dummy_target_xxx ALL DEPENDS
"${CMAKE_CURRENT_BINARY_DIR}/output.rb.in"
)
configure_file (
"${CMAKE_CURRENT_BINARY_DIR}/output.rb.in"
"${CMAKE_CURRENT_BINARY_DIR}/output.rb"
)
install (
FILES "${CMAKE_CURRENT_BINARY_DIR}/output.rb"
DESTINATION "${RUBY_VENDOR_LIBDIR}/myvendor"
)
CMake complains with the error
CMake Error: File /home/user/myproject/build/output.rb.in does not exist.
CMake Error at CMakeLists.txt:35 (configure_file):
configure_file Problem configuring file
when running an out-of-tree build. Any ideas?
configure_file() is executed immediately at configuration step, while add_custom_command() add command to be executed(and dependency to be evaluated) at build step.
You may either replace add_custom_command with appropriate execute_process call, so your ruby script will be executed at configuration step, and its output file will be ready for configure_file.
Or you may replace configure_file with appropriate add_custom_command, so your file will be configured at build step, and will see dependencies. The problem here that you should explicitely pass CMake variables, used in "output.rb.in" file, to the configuration program, which can be, e.g.,
${CMAKE_COMMAND} [-D<var-definition>]+ -P <cmake-script-file-which-calls-configure_file>
In this particular case, it was sufficient to reorder to configuration operation, by performing configure_file() first, and pipe the output of this into the custom command.. I was merely thinking of the ordering all wrong.
I still do not have an answer for adding generated dependency to the input of configure_file()
Complete code
configure_file (
"${CMAKE_CURRENT_SOURCE_DIR}/input.cmake"
"${CMAKE_CURRENT_BINARY_DIR}/output.rb.in"
)
# Custom command to build the output.rb
add_custom_command (
OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/output.rb"
COMMAND ruby ${CMAKE_CURRENT_SOURCE_DIR}/build_ruby_output.rb
-i ${CMAKE_CURRENT_BINARY_DIR}/output.rb.in
-o ${CMAKE_CURRENT_BINARY_DIR}/output.rb
)
# Custom target is required to build it
add_custom_target (
dummy_target_xxx ALL DEPENDS
"${CMAKE_CURRENT_BINARY_DIR}/output.rb"
)
install (
FILES "${CMAKE_CURRENT_BINARY_DIR}/output.rb"
DESTINATION "${RUBY_VENDOR_LIBDIR}/myvendor"
)
I wrote a very simple HelloWorld.c program and ran Cmake. It created a cmake_install.cmake file in my build directory. Can somebody explain to me why CMake generated the file cmake_install.cmake? What is it's purpose and how can I use it?
CMakelists.txt :
cmake_minimum_required(VERSION 3.0)
PROJECT(FirstExample)
add_executable(prog first.c)
Thanks!
You generally don't use cmake_install.cmake directly. From the v3.12 page it states:
The install() command generates a file, cmake_install.cmake, inside
the build directory, which is used internally by the generated install
target and by CPack.
With your current CMakeLists.txt, the generated file doesn't do much. To create a useful install you would need to add more INSTALL commands to your CMakeLists.txt using the syntax below.
INSTALL(TARGETS targets... [EXPORT <export-name>]
[[ARCHIVE|LIBRARY|RUNTIME|FRAMEWORK|BUNDLE|
PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE]
[DESTINATION <dir>]
[INCLUDES DESTINATION [<dir> ...]]
[PERMISSIONS permissions...]
[CONFIGURATIONS [Debug|Release|...]]
[COMPONENT <component>]
[OPTIONAL] [NAMELINK_ONLY|NAMELINK_SKIP]
] [...])
For further reading on this command, check out the documentation site and wiki.
If it's desired to manually execute the script as stated by Nic30g the 3.12 page states that cmake -P accepts the following variables:
COMPONENT
Set this variable to install only a single CPack component as opposed to all of them. For example, if you only want to install the Development component, run
cmake -DCOMPONENT=Development -P cmake_install.cmake
BUILD_TYPE
Set this variable to change the build type if you are using a multi-config generator. For example, to install with the Debug configuration, run
cmake -DBUILD_TYPE=Debug -P cmake_install.cmake.
DESTDIR
This is an environment variable rather than a CMake variable. It allows you to change the installation prefix on UNIX systems. See DESTDIR for details.
As previous answer tells, the cmake_install.cmake contains the commands generated by install command from your CMakeLists.txt.
You can execute it by cmake -P cmake_install.cmake and it performs the installation of your project even on windows.
https://cmake.org/pipermail/cmake/2007-April/013657.html