I have this problem with cmake:
In the top level CMakeLists.txt:
set(MY_INCLUDE_DIR "/path/to/dir")
In the lower level CMakeLists.txt:
include_directories(${MY_INCLUDE_DIR})
GCC, through the make command, returns a "No such file or directory" relative to the line that includes the file located in MY_INCLUDE_DIR.
However, if I move the set line in the same lower level file where I specify the include directories, everything is fine.
In the documentation it is clearly written that lower level files inherit what is in the higher level ones.
What is wrong in my files?
Thank's.
Related
What exactly is the -i option of the Delphi dcc command-line compilers (dcc32.exe, dcc64.exe, dcclinux64.exe and others)? As opposed to -u? Help just states this briefly (and Embarcadero documentation does not seem to expand upon the subject):
-I<paths> = Include directories
-U<paths> = Unit directories
For a while, I thought that -u is for including source code and -i for including precompiled .dcu files, but that does not seem to be the case. I also see cases where -i imports source code and -u imports .dcu files, and also that seems to work just fine. Another thought is that -u is meant to be the counterpart of the project's Search path in the Delphi IDE, and -i the counterpart of the Delphi IDE's global Library path, but that does not seem conclusive, either.
When should I use one or the other, -i or -u?
The Remarks section of this page http://docwiki.embarcadero.com/RADStudio/Sydney/en/Include_file_(Delphi) begins
The $I parameter directive instructs the compiler to include the named file in the compilation. In effect, the file is inserted in the compiled text right after the {$I filename} directive.
The default extension for filename is .pas. A filename specified with no file extension always gets the .pas extension. If the filename does not specify a directory path, then, in addition to searching for the file in the same directory as the current module, Delphi searches in the directories specified in the Search path input box on the Delphi Compiler page of the Project > Options dialog box (or in the directories specified in a -I option on the command line compiler). ..."
The important thing to understand is that this is not talking about searching for source files in general, but rather for single files named in a source file by an
{$inc }
or
{$include }
directive in a source file. For example
unit SomeUnit;
{$inc SomeIncludeFile}
interface
[...]
Files named inside an {$inc} or {$include} directive are known as "include files" - hence the title topic of the quoted page. Subject to the restriction noted in the final paragraph of the Remarks, the directive can appear pretty much anywhere in a source file and, during compilation, the compiler substitutes the contents of the named file for the directive (including the filename). The support for include files in Turbo Pascal pre-dates its support for units and was primarily to ensure that two or more source files could behave as if they contained identical text, for example shared code or definitions.
The -i setting tells the compiler one or more folders in which to look for files such as SomeIncludeFile which are named by include directives the compiler encounters while compiling the source files in a project.
The -u setting tells the compiler where to look for unit files (e.g. .Pas and .Dcu ones) during a compilation.
I am currenly working on an erlang project and stuck in reading the file. I want to read a text file which is in the /src folder where all the erlang and a text file are in the same structure. Then too, I am not being able to read the file despite of specifying file paths. Any help would be appreciated.
start() ->
{ok,DataList} = file:consult("Calls.txt"),
io:format("** Calls to be made **"),
io:fwrite("~w~n",[DataList]).
The data file stores contents like : {john, [jill,joe,bob]}.
Try add folder name to the path or try set full patch to the file:
1> {ok,DataList} = file:consult("src/Calls.txt").
Notes: the error {error,enoent} mean that the file does not exist or you don't have a rights to read/write current file, for this case need set 777 rights or similar.
If you need to use src/call.txt, then this simply means that your IDE (or you) has created a src folder in which the calls.txt file has been placed. At the same time, the IDE is using a path that only includes the top level folder (i.e., the root folder for the IDE project). So src/call.txt must be used in that case. This isn’t a problem with Erlang, or even the IDE. It’s just the way your project is set up.
You can do either of two things. Move the calls.txt file up one level in the IDE file manager, so that it can be referenced as calls.txt, not src/call.txt. You can also just change the path to “calls.txt” before you run it from the command line.
enoent means "Error: No Entry/Entity". It means the file couldn't be found. When I try your code, it works correctly and outputs
[{john,[jill,joe,bob]}]
I've got an iOS framework that has a dependency on the (presumably Google maintained) pod called '!ProtoCompiler'. In order to build my framework I'm going to need it in the sandbox. So, I have a genrule and can try to include it with
src = glob(['Pods/!ProtoCompiler/**/*']) but I get the following error:
ERROR: BUILD:2:1: //Foo:framework-debug: invalid label 'Pods/!ProtoCompiler/google/protobuf/any.proto' in element 1118 of attribute 'srcs' in 'genrule' rule: invalid target name 'Pods/!ProtoCompiler/google/protobuf/any.proto': target names may not contain '!'.
As is, this seems like a total blocker for me using bazel to do this build. I don't have the ability to rename the pod directory as far as I can tell. As far as I can tell, the ! prohibition is supposed to be for target labels, is there any way I can specify that this is just a file, not a label? Or are those two concepts completely melded in bazel?
(Also, if I get this to work I'm worried about the fact that this produces a .framework directory and it seems like rules are expected to produces files only. Maybe I'll zip it up and then unzip it as part of the build of the test harness.)
As far as I can tell, the ! prohibition is supposed to be for target
labels, is there any way I can specify that this is just a file, not a
label? Or are those two concepts completely melded in bazel?
They are mostly molded.
Bazel associates a label with all source files in a package that appear in BUILD files, so that you can write srcs=["foo.cc", "//bar:baz.cc"] in a build rule and it'll work regardless of foo.cc and baz.cc being a source file, a generated file, or a build rule's name that produces files suitable for this particular srcs attribute.
That said you can of course have any file in the package, but if the name won't allow Bazel to derive a label from it, then you can't reference them in the BUILD file. Since glob is evaluated during loading and is expanded to a list of labels, using glob won't work around this limitation.
(...) it seems like rules are expected to produces files only. Maybe
I'll zip it up and then unzip it as part of the build of the test
harness.
Yes, that's the usual approach.
I have C++ header file dependencies that I specify in my waf script with the includes=... parameter to bld.program().
I know the waf build configuration sees the includes because my program compiles correctly.
However, when I change a header file, waf does not detect the change. That is, when I run waf build after changing the contents of an included header, nothing gets recompiled.
Isn't waf supposed to determine #include "..." dependencies automatically?
How can I troubleshoot this?
I have looked in the build/c4che directory to see if I could make sense of the configuration files stored there. Mention of "include" in the waf generated .py files is suspiciously absent.
I am using waf version 1.9.0.
I have also tried this with waf 1.8.19 and got the same result.
EDIT: I replaced my original complicated wscript with the much simpler one listed below, and I still get the same behavior.
Here is my wscript:
top = '.'
out = 'build'
CXXFLAGS = ['-fopenmp', '-Wall', '-Werror', '-std=c++11', '-Wl,--no-as-needed']
def options(ctx):
ctx.load('compiler_cxx')
def configure(ctx):
ctx.load('compiler_cxx')
ctx.env.CXXFLAGS = CXXFLAGS
def build(ctx):
ctx.program(source="test_config_parser.cpp", target="test_config_parser", includes=["../include"], lib=['pthread', 'gomp'])
Your problem is that you use includes out of the project's directory. By default waf does not use external includes as dependencies (like system includes) to speed up things. Solutions I know of :
1/
Organize your project to have your include directory under the waf top directory :
top_dir/
wscript
include/
myinclude.h
sources/
mysource.cpp
2/
Change top directory. I think top = .. should work (not tested).
3/
Tell waf to go absolute by adding this lines at the beginning of build():
waflib.Tools.c_preproc.go_absolute=True
waflib.Tools.c_preproc.standard_includes=[]
4/
Use gcc dependencies by loading the gccdeps waf module.
Solution 1/ is probably the best.
By the way I prefer to have my build directory out of the source tree. Use out = ../build in your wscript, if you want to build out of the source tree.
my2c
Inspecting an archived app, I can see the full path listed for a few source code files in the app binary. Not all source code files are listed.
strings - the_binary_app | grep "\.m"
reveals
/Users/bbarnhart/myPath/myPath/App/path/path/SourceCodeFile.m
as well as a few others. I can not determine how the full paths for a few source code files are embedded in the app binary. I would like to remove them. Any ideas? Is this a build setting or is the project file slightly corrupted?
Some belong to a lib and others are files that belong to the project.
The __FILE__ macro expands to full path to the current file. This is one likely way you might be getting the paths into your executable. For example, the expansion of the assert macro includes the __FILE__ macro.
Look at the output of your strings | grep pipeline. For each of those files, go into your project in Xcode and open that file. Then go to the Related Files doodad and choose “Preprocess”:
Then search through the preprocessor output for the file's path. You will find lots of false positives, because there will be lots of # line number/path directives. You can ignore these, because they only produce debug output, which is not included in your executable file (unless you've done something weird with your build settings). You might find it faster to save the preprocessor output to a file, then open that file and pipe it through grep or use a regexp search/replace to delete all lines starting with #.
Find the other instances where your path appears as a string constant. For example, if you used the assert macro, you will find something like this:
(__builtin_expect(!(argc > 0), 0) ? __assert_rtn(__func__, "/Volumes/b/Users/mayoff/TestProjects/textViewChanged/textViewChanged/main.m", 16, "argc > 0") : (void)0);
That's a case where the path will end up embedded in your executable.
If that doesn't find all the places where you're embedding your path, try selecting “Assembly” from the Related Files doodad. The assembly will be full of comments containing your path; everything after # is a comment in the assembly output, so ignore those.
You will also see your paths in .file directives. I believe these only produce debug symbol output, which doesn't go into your executable, so you can ignore those too.
You will also see your paths in .asciz directives shortly after .section DWARF,... directives. This is more debug symbol stuff that you can ignore.
Look for the remaining cases where your path appears in the assembly output. You need to figure out how to eliminate these cases. How you do that will depend on the context in which the paths appear, so if you need more help, update your question with what you find.
Sounds like your code contains the __FILE__ macro somewhere.