CMake: Header files cannot be opened - c

I am working to build a Code Composer Studio project using cmake, which is new to me. It builds successfully under Linux but I am struggling to get it to work under Windows. The cmake command executes without issue, but make fails during the very first C object at the very first #include with the error code
fatal error: could not open source file "stdbool.h" (no directories in search list)
I'm using the libraries included in CCS's compiler (c6000_7.4.15), and that whole folder is included in the CSS project. I include it in cmake as well. In my .cmake file:
set (CCS_ROOT ${CCS_ROOT_V6_WIN} CACHE PATH "code composer install directory")
set(CGT_COMPILER_ROOT ${CCS_ROOT}/tools/compiler/c6000_7.4.15 CACHE INTERNAL "DSP Compiler Root")`
And in the CMakeLists.txt file:
set (COMPILER_INCLUDE ${CGT_COMPILER_ROOT}/include)
INCLUDE_DIRECTORIES ("${COMPILER_INCLUDE}")
Why can the header files not be opened when they're linked in the project and CMake can find them just fine?
EDIT: The directory structure had been changed underneath me, so I took the opportunity to add all of the external files directly into the project to make it completely platform-independent. That way, since the project is managed by our Git repository, users won't have to install the CSL or any other programs to build the project. This also means that paths to libraries and header files will never change between revisions and environments.
Unfortunately, this has not solved my problem. The project continues to build in Linux while failing to ind the very first included header file. I also notice that, under Windows, it cannot find my own header files unless I provide a relative path, e.g. #include "../Common.h" I can get make to find stdbool.h if I provide an absolute path to the compiler directory, but that exposes a web of additional broken links between files.
As a side note, the project builds successfully within Code Composer Studio, so I am assuming that this isn't an issue with my specific Windows environment nor with the code within the project itself.

This seems to be an issue with gcc.exe. I set an environment variable CC to the path of a different compiler (in my case a TI compiler) within my build script and that fixed the problem.

Related

How can I include necessary kernel32.lib, headers - or use the standard dll in a custom application?

I try to build the Airspy library but I'm having issues, it is not even including Kernel.h headers? I changed Windows SDK in project settings to no effect, and now I am seeing odd errors relating to what seems like perfectly fine syntax:
This is Win8.1 and I tried both in the settings, installing both, but still not compiling. I want to use the library to read audio from radio device but the necessary library isn't compiling (or can I include an Airspy dll and forgo the compile and build step here?)
>> it is not even including Kernel.h headers?
This library is not necessarily used in this header file. It may be used in other header files.
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib , this is the path of kernel32.lib. 1. Confirm the existence of this file. 2. check your Library Directories of VS and confirm that you fill in the path. This is a common solution to the problem of missing files.

Why can't I load GLScene as a package in C++Builder?

I am trying to use GLScene (a third-party FireMonkey component for C++Builder and Delphi). I downloaded the zip, and in it, among other things, are .bpl files for use in C++Builder. When I try to install the package in my project (a C++Builder multi-device application) under Component > Install Packages... > Add, I get this error:
My directory structure:
The _Installation directory and the Readme's are not very helpful. I have tried the other .bpl files and also tried importing all of them at once, but the same error occurs. How do I fix this?
There are several problems.
The XE3 extension is suspicious. I just downloaded and unzipped the GLScene download. The .BPLs in the CBXE3 and CBXE4 seem to be compiled for XE3 and XE4 respectively. But packages are version-dependent.
You should recompile the sources (also included) for 10.2 Tokyo. Just copy the DelphiXE4 directory to a new directory, and load the .groupproj file or the single .dpk files into the IDE. You might want to change the suffixes (currently XE3) of the packages to, say, Tokyo, in the project options, to avoid DLL (or BPL) hell.Also take a look at the pictures in the _Installation directory for the other options that must be set. Note that your paths may differ, theirs are just an example.
The compiler needs to be able to find the .bpi and .lib etc. files in order to be able to link. Set the directories with those files in the project options, as shown in the _Installation pictures.
The newly compiled .bpl files should be compiled to a directory on the Windows path, so they can be found by the system at runtime. In their example setup, (and in the _Installation pictures) that is the shown C:\Library\GLScene path.

cmake and file paths in source code

How does one properly use file paths in source code (relative to the project root) when building with cmake?
Details:
I have a cmake project with basically this layout:
project
|-src/
| |-main.c
| |-CMakeLists.c
|-dat/
| |-foo.txt
|-build/
main.c basically contains a main function that tries to open a file, specified relative to the project's root directory, i.e., dat/foo.txt. When building with cmake, the binaries are located in project/build/src, which is also the working directory when running the program. dat/foo.txt is interpreted as project/build/src/dat/foo.txt which obviously is not available. One could replace the path in the source file with ../../dat/foo.txt, which however is not at all a clean and nice solution.
This stackoverflow post states that there is no easy way for setting the working directory of code executed by cmake (furthermore, the answer refers to a solution for Visual Studio, which I am not using).
What is the best practice for this problem?

How do you configure XCode to find header files and symbols in an "External Build System" project

I'm trying to set up an XCode 5.1 project for C php-extension development. This is essentially a GNU autoconf/automake project with one prerequisite step.
I created a new "External Build System" project. I then made two targets, one that runs the prerequisite "phpize" command that creates GNU autoconf files. I have another target that runs the GNU ./configure script. This all works great.
Next, I tried adding my .c and .h files to the project. When I open them, and try to click on any #include .h file or any external symbol, XCode says "symbol not found", even for system stuff like <stdio.h>.
In a normal XCode project, there is a way to configure the header/include search paths. With this external build system project, I see no way to do this.
My questions:
For a project that uses ./configure and make, is the "External Build System" project type the correct type?
If so, then in this project type, how do I set the header/include search paths so that code navigation works?
Analyze doesn't seem to work right, either.

How can I link the source path of a compiled library to a different location in Eclipse?

I've installed the msp430-gcc compiler and associated tools to do some open-source msp430 development at home using Eclipse. I'm developing on a slightly older Macbook Pro running OS X Lion and installed the tools using MacPorts. I'm running Eclipse 3.7.2 with the CDT and GCC Cross Compiler Support plug-ins. I have a simple empty main() written that compiles and links just fine.
The ELF parser lets me view the contents of the ELF binary just fine with the exception of one component; when I try to view the contents of the startup code in crt0.S, it gives me a blank file. When I click on the crt0.S component of the ELF, the filename bar at the bottom of the Eclipse window shows "/opt/local/var/macports/build/_Volumes_work_mports_dports_cross_msp430-gcc/msp430-gcc/work/gcc-4.6.3/gcc/config/msp430/crt0.S". This makes sense because of my MacPorts install of msp430-gcc. crt0.S is archived into /opt/local/lib/gcc/msp430/4.6.3/libcrt0.a on my machine.
What I want to be able to do is tell Eclipse to look elsewhere for the source files for the libraries that are automatically linked when I build with the msp430-gcc toolchain. This would presumably include everything in /opt/local/lib/gcc/msp430/4.6.3/. I started by downloading the source for mspgcc-20120406 (the version in my MacPorts install) and applying the gcc patchfile to an empty directory tree. This created the gcc/config/msp430 directory, including the crt0.S and crt0ivtbl.S files.
What I have had no luck accomplishing is telling Eclipse to look in ~/Developer/mspgcc-20120406/gcc-4.6.3/config/msp430/ instead of the path that's in the already-built libcrt0.a. I tried playing around with the Project Preferences->Paths and Symbols->Source Location window, but didn't have much luck. I searched through this website and on Google and the closest thing I came up with was this question but it doesn't "smell" like the right answer.
I would like to avoid solutions that involve moving the library source into my project. I'd rather have a solution that will work for multiple projects.
All help is greatly appreciated! Thanks in advance.
Try and check if the Eclipse linked resource could help you declare that external directory from within your Eclipse project here.
Linked resources are files and folders that are stored in locations in the file system outside of the project's location. These special resources can be used to add files and folders to your project that for some reason must be stored in a certain place outside of your project. For example, a linked folder can be used to store build output separately from your source files.
I find interesting how you can define that linked resource:
Linked resource target paths can be either defined as absolute paths, or relative to a path variable.
Since you can define it relative to (for instance) your Eclipse project location PROJECT_LOC, you can then setup your resource in a way which won't change between two environments.

Resources