Related
I have a Makefile that includes another makefile with the include makefile directive and the included Makefile exists on a deep path (200 characters). The Makefile doesn't produce any error on reading the long path Makefile however it's contents are not included in the main Makefile.
include <long-path>/my.mk
I have tried using UNC path post script as well but that also seems to have no effect. Any help how to handle long paths inclusions in Makefiles?
There can be different ways on how you handle this:
Provide Relative Path: A relative path refers to a location that is relative to a current directory, so you dont require to give a full path
Keep your files/sandbox at very short location if possible: Eg: C:
You can use mount/ shortpath option to use short paths.
I have a Makefile with only project-level definitions: which source files to use, what binary or library to make, etc..
It includes ../../Make.Arch for architecture-specific definitions (such as compiler command).
In turn, Make.Arch is meant to include ../etc/Makefile.Standard for all the boilerplate of actually allowing the make system to work .
But include requires a path relative to where the makefile is actually being run (or maybe where the first Makefile is), not relative to the second... What to do?
Make interprets relative paths from the working directory, the directory in which Make is being run. You haven't specified how you're running Make, so I'll assume your running it in the directory with Makefile.
If you are allowed to modify the makefiles, you can change the paths.
You could change Make.Arch from this:
include ../etc/Makefile.Standard
to this:
include ../../../etc/Makefile.Standard
but that would require that any makefile that uses Make.Arch be two directories down from it. That's clearly not a good idea. But we can use a variable:
include $(ARCH_DIR)/../etc/Makefile.Standard
which is provided by Makefile (or any other makefile that uses Make.Arch):
ARCH_DIR := ../..
include $(ARCH_DIR)/Make.Arch
If you are not allowed to modify the makefiles, then you must cheat. One way is to create a symbolic link to Makefile.Standard.
mkdir ../etc
ln -s ../../../etc/Makefile.Standard ../etc
Now Makefile will work. (It ought to be possible to make a link to etc/, but for some reason I can't get that to work right now.)
In a project I have an already created shared library called, let's say, 'myshare'. The library is already created as 'libmyshare.so.1.0.0' and its location is relative to the makefile at a relative address of 'adir/lib'.
In the makefile I want to create symbolic links for the shared library with the names 'libmyshare.so.1' and 'libmyshare.so'. In order to do this in the makefile I have these lines:
MYSHAREL = ./adir/lib/libmyshare.so.1.0.0
MYSHAREL1 = ./adir/lib/libmyshare.so.1
MYSHAREL2 = ./adir/lib/libmyshare.so
MYSHARELIBS = $(MYSHAREL) $(MYSHAREL1) $(MYSHAREL2)
.PHONY: all
all: myexetarget
myexetarget : various_files $(MYSHARELIBS)
various_commands_to_make_target
$(MYSHAREL1): $(MYSHAREL)
#echo "Creating symbolic link $(MYSHAREL1)"
#ln -s $(MYSHAREL) $(MYSHAREL1)
$(MYSHAREL2): $(MYSHAREL)
#echo "Creating symbolic link $(MYSHAREL2)"
#ln -s $(MYSHAREL) $(MYSHAREL2)
When I run the 'make' command the links to the shared library are always created even when they already exist and even when the date of the shared library is prior to the date of already created symbolic links. Furthermore when I try to actually link to the shared library in my target, despite an -L./adir/lib and -lmyshare options among the linker options ( not shown above ) the link fails with:
/usr/bin/ld: cannot find -lmyshare
Both these problems lead me to believe that I am not specifying the name or relative location of the shared library correctly for the makefile processing to understand it. Does anybody know what I am doing wrong ?
Your use of ln -s is probably the cause of your problem. If, from your top directory you execute:
ln -s ./adir/lib/libmyshare.so.1.0.0 ./adir/lib/libmyshare.so.1
(which is what your make rule does) a symbolic link is created in ./adir/lib, named libmyshare.so.1 and pointing to ./adir/lib/libmyshare.so.1.0.0:
$ cd ./adir/lib
$ ls -l
libmyshare.so.1 -> ./adir/lib/libmyshare.so.1.0.0
libmyshare.so.1.0.0
So, ./adir/lib/libmyshare.so.1 actually points to ./adir/lib/adir/lib/libmyshare.so.1.0.0 that does not exist.
You can replace your ln -s command by:
#ln -sr $(MYSHAREL) $(MYSHAREL1)
Same for MYSHAREL2. The -r option of ln create symbolic links relative to link location.
I have a project that uses CMake to generate build scripts, and each platform puts the executable that are generated in a different place. We have a non-programmer on our team who does not have build tools and I want to be able to bundle up all the files, scripts and executables necessary to run the project so that he can run the project.
To do that, I've added a custom target that takes all the necessary files and zips them up. It also generates a very simple script (which is included in the zip file) that he can just click on that should run a script then launch the executable, like so:
add_custom_target(runcommand
COMMAND echo '\#!/bin/bash -eu' > run.command &&
echo 'cd `dirname $$0`' >> run.command &&
echo './scripts/prerun_script.sh && ${MY_EXECUTABLE}' >> run.command &&
chmod +x run.command)
The problem with this is that MY_EXECUTABLE is a hardcoded path to the executable on my system. I would like it to be a relative path so that I can just take this resultant zip file, unzip it anywhere and run it from there. What I would like is to get the path to MY_EXECUTABLE relative to the root directory of my project so that this script can be run from anywhere.
You can use:
file(RELATIVE_PATH variable directory file)
Concretely, assume that MY_ROOT contains the root directory (there might be a suitable predefined CMake variable for this), this will set rel to the relative path of MY_EXECUTABLE:
file(RELATIVE_PATH rel ${MY_ROOT} ${MY_EXECUTABLE})
In case where you want to get path relative to project root, you may use PROJECT_SOURCE_DIR CMake variable:
file(RELATIVE_PATH rel ${PROJECT_SOURCE_DIR} ${MY_EXECUTABLE})
Remember, that MY_EXECUTABLE must contain full path to file.
get the relative path to the current source directory
file(RELATIVE_PATH relative ${CMAKE_SOURCE_DIR} ${CMAKE_CURRENT_SOURCE_DIR})
Test:
message(STATUS "source base: \"${CMAKE_SOURCE_DIR}\"")
message(STATUS "current: \"${CMAKE_CURRENT_SOURCE_DIR}\"")
message(STATUS "relative: \"${relative}\"")
Result:
--source base: "C:/Project/Software/Test/source"
--current: "C:/Project/Software/Test/source/unittest/libs/fsm
--relative: "unittest/libs/fsm"
Something like this would work:
THISDIR=`pwd`
MY_EXECUTABLE=$THISDIR/test/someexec
REL_EXECUTABLE=${MY_EXECUTABLE##$THISDIR/}
echo $REL_EXECUTABLE
Basically, this chops off the base path from $MY_EXECUTABLE. In this example, I just set up MY_EXECUTABLE as a test to give it a full path. The one-line equivalent for what you want is:
${MY_EXECUTABLE##`pwd`/}
I guess this assumes pwd is the root of your project. Otherwise, see the Cmake variable doc.
(As an aside, this makes me nostalgic for the ksh days.)
This is a GNU Make dependency resolution issue.
My problem is that I copy the source files from a remote file server to a scratch disk (which speeds up the build process by 50%). If the file copy fails, I want to use the source files from the file server, else I want to read them from the scratch disk.
I have tried to use the vpath mechanism, but the problem is that, as far as I understand, make will by default start looking for the source files in the current directory and only if it fails to find the files there, look in the directories listed with vpath.
Is it possible to have make first look in the vpath directories before looking in the current directory? Or perhaps only look in the vpath directories (and explicitly and dynamically add the current directory to vpath)?
Only way I can think of is to temporary change directory so that make always will fail to find the source files.
Look at the path to the source directory on the server. Suppose it's "/server/someplace/src/". And suppose you don't have a "src" directory in the current directory (if you do, we just have to tweak this method). Just make sure that the path to the source directory on the scratch disk ends in "/src/", such as "/scratch/wednesday/src/". Then you can do this:
SCRATCH_PATH = /scratch/wednesday/
SERVER_PATH = /server/someplace/
VPATH = $(SCRATCH_PATH) $(SERVER_PATH)
%.o: src/%.cc
$(CC) blah blah blah