I want to write a make file to compile my source code. I have to put in my make file the includes paths but i have a lot of folders with source codes.
In make file i have a list with all .c files like this :
__MDA_SRC = \
$(__VIEWPATH)\f_03\test\mda\src\mda.c
now i need to find out the path of this file.
I tried this one :
__PATHS_FEATURE = \
$(dir $(__MDA_SRC ))
__INCLUDE_PATHES := \
-I$(__PATHS_FEATURE)
but i have an error F100: cannot open ...bla bla..
i supposed that the problem is on the path, because the path is extructed with the last backslash like:
..\..\..\..\..\f_03\test\mda\src\
How could i have the path without the last backslash like this :
..\..\..\..\..\f_02\hydraulic\btc\src
That seems unlikely to be the problem to me but you can remove it with
$(__PATHS_FEATURE:\=)
or
$(patsubst %\,%,$(__PATHS_FEATURE))
This may not work for your problem since your path is not absolute, however the 'abspath' and 'realpath' indirectly do what you are looking for. 'realpath' will remove the last forward slash as well as any . .. or repeated /
pathwslash=/dirs/and/more/dirs/
path=$(realpath $(pathwslash))
echo $(path) # /dirs/and/more/dirs
Here is some documentation for some other functions that may be helpful: https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html
Related
Ok so i did something very stupid (copying a file and renaming it '.') since I thought it would just copy it as .uniprot_sprot.fasta.gz.icloud.
cp /path/.uniprot_sprot.fasta.gz.icloud .
and now I don't know how to remove it from current directory as it would be removing '.' itself.
What can I do?
This doesn't work. It says: No such file or directory
rm .uniprot_sprot.fasta.gz.icloud
On the other hand:
ls -a
gives this:
.
..
uniprot_sprot.fasta.gz.icloud
You have not copied a file and renamed it . (at any rate if you're running a sane *nix). Instead you have copied the file to the current directory with the name of the original file. (If you pass a directory to cp as the destination, files will be placed in that directory. . is the current directory, so this is all that has happened.) If you want to remove it you can just rm uniprot_sprot.fasta.gx.iscloud or explicitly rm ./uniprot_sprot.fasta.gx.iscloud. What you have tried to do is to remove a file whose name starts with ., which is a different thing.
Edit: I was unaware when I wrote this, but this is in fact simply down to . existing as a real, regular hardlink. At syscall level you can create a file whose name contains anything except / and \x00 (yep, including \n), assuming your filesystem allows it. However, the links . and .. are already present and thus unavailable as a file name. #thatotherguy links to the kernel source for the rmdir syscall, showing that in modern Linux at least it is the kernel itself which ultimately prevents you from deleting . and ...
Note that in bash, . at the beginning of a line by itself means source.
See this question on unix.se and its linked dupe for more information on the filename problem.
I'm trying to install a grunt template on my computer but I'm having issues. I realized that perhaps something different is happening because of the path given by the Grunt docs, which is
%USERPROFILE%\.grunt-init\
What does that . mean before grunt-init?
I've tried to do the whole import manually but it also isn't working
git clone https://github.com/gruntjs/grunt-init-gruntfile.git "C:\Users\Imray\AppData\Roaming\npm\gru
nt-init\"
I get a message:
fatal: could not create work tree dir 'C:\Users\Imray\AppData\Roaming\npm\.grunt-init"'.: Invalid argument
Does it have to do with this /.? What does it mean?
The \ (that's a backslash, not a slash) is a directory delimiter. The . is simply part of the directory name.
.grunt-init and grunt-init are two distinct names, both perfectly valid.
On Unix-like systems, file and directory names starting with . are hidden by default, which is why you'll often see such names for things like configuration files.
The . is part of a directory name. Filenames can contain . . The \ is a separator between directory names.
Typically, files or directories starting with . are considered "hidden" and/or used for storing metadata. In particular, shell wildcard expansion skips over files that start with ..
For example if you wrote ls -d * then it would not show any files or directories beginning with . (including . and .., the current and parent directories).
Linux hides files and directories whose names begin with dot, unless you use the a (for "all") option when listing directory contents. If this convention is not followed on Windows, your example is probably just a carryover.
It may well be something behind the scenes (later) expects that name to match exactly. While I like things, installers, for example, to just do what I said, I realize that keeping default value is the most tested path.
Directories starting with a dot are invisible by default on xNIX systems. Typically used for configurations files and similar in a users home directory.
\ before " has a special meaning on windows, the error is because windows won't let you create a file containing " as part of its name.
I try to loop over the file I findin a relative path to build a list of relative path/soure file name=source file name
SHARED_LIB_PACK=""
for LIB in $(find ../level1/leve2/ -name "*.so*")
do
$SHARED_LIB_PACK=$SHARED_LIB_PACK" "$LIB"="${LIB##*/}
done
but as I run it, it complain :
line 6: = ../level1/level2/file.so.1.0=file.so.1.0: No such file or directory
Any help will be welcome
Firstly, variable assignment is done via:
FOO="bar"
and not
$FOO="bar"
The former will not work.
Secondly, your quotes seem to be in strange places:
SHARED_LIB_PACK=$SHARED_LIB_PACK" "$LIB"="${LIB##*/}
should probably be
LIB="${LIB##*/}"
SHARED_LIB_PACK="$SHARED_LIB_PACK $LIB"
or
SHARED_LIB_PACK="$SHARED_LIB_PACK ${LIB##*/}"
When I tried including a file on Unix (and Windows) it won't work when it includes spaces. For example, these won't work:
include ~/Space Folder/test.fs
include ~/Space\ Folder/test.fs
include "~/Space Folder/test.fs"
include "~/Space\ Folder/test.fs"
include C:\Users\Lim Ding Wen\test.fs
include C:\Users\Lim/ Ding/ Wen\test.fs
include "C:\Users\Lim Ding Wen\test.fs"
So.. is there a way to make this work? Thanks!
Use the included word :
s" My File With Spaces.fs" included
Tilde expansion will probably not work (haven't tested). If you do not specify an absolute path, then the file needs to be in the GFORTHPATH
I have added a include directory in my home directory. I can run "ls -l ~/include" from the build directory.
I have added that directory in both "Header Seach Path" and in "User Header Search Path". In both places I have tried with both non-recursive and recursive.
But xcode 4.5.1 can not in any situation find the first stated header file.
It is stated in source code calls.m as:
#include <directory/file.h>
I get a "Lexical or Preprocessor issue 'directory/file.h' file not found."
But when running xcodebuild from cli it has no problems what so ever to build the source.
I have tried many of the suggestions found on internet
Putting a include in /usr/ om my drive
Adding a index to the project, adding files with no copy and no "Add to target" marked.
Restart xcode.
Specifying all specific paths.
But still no go.
What is the problem. Bug´s in xcode?
I just had a similar issue, and it was because there were spaces in the path which I defined for the Header Search Path. For example, I was defining the following as a search path:
$(SRCROOT)/Frameworks/Headers
which was being expanded out to the following:
/Users/skoota/Documents/Xcode Projects/My App/Frameworks/Headers
as you can see, there are spaces within the path (which are not immediately evident, as you are using the $(SRCROOT) variable) and the compiler doesn't particularly appreciate the spaces. I solved this problem by changing the search path to this:
"$(SRCROOT)"/Frameworks/Headers
(note the quote marks around $(SRCROOT) which escapes the spaces). This now expanded out to:
"/Users/skoota/Documents/Xcode Projects/My App"/Frameworks/Headers
which works perfectly, although looks a bit odd with the embedded " marks. This took me a while to figure out, so hopefully it helps!
This usually happens if there are spaces in your directory's path. To overcome this problem, use double quotes around the path.
Suppose you want to use your project directory, then you should use: $PROJECT_DIR. Enable recursive if you want to search within the folders as well. Alternatively, you can use $(SRCROOT)