Clion 1.1.1 use CMakeList.txt to add library headers for unity - unity3d

I never used CMake before so please excuse me.
My project has a "unity" folder that contains version 2.3.0 of the unit test library). unity_fixture.h contains "#define TEST(..." which is used like the following:
#include "unity_fixture.h"
...
TEST(xformatc, Simple) {
char output[20];
TEST_ASSERT_EQUAL(13, testFormat(output, "Hello world\r\n"));
TEST_ASSERT_EQUAL_STRING("Hello world\r\n", output);
}
I added "include_directories(${CMAKE_SOURCE_DIR}/unity)" to my CMakeLists.txt file. Still CLion does not find the declaration of TEST and I get tons of errors.
I did try to add all the unity files with set(SOURCE_FILES unity/unity_fixture.h..." but this did not work either.
edit 08.09.2015
I found out something strange. If I call cmake from command line it creates a file "DependInfo.cmake" with the following contents:
# The set of languages for which implicit dependencies are needed:
set(CMAKE_DEPENDS_LANGUAGES
)
# The set of files for implicit dependencies of each language:
# Targets to which this target links.
set(CMAKE_TARGET_LINKED_INFO_FILES
)
# The include file search paths:
set(CMAKE_C_TARGET_INCLUDE_PATH
"unity"
"cmsis/inc"
"freertos/inc"
)
set(CMAKE_CXX_TARGET_INCLUDE_PATH ${CMAKE_C_TARGET_INCLUDE_PATH})
set(CMAKE_Fortran_TARGET_INCLUDE_PATH ${CMAKE_C_TARGET_INCLUDE_PATH})
set(CMAKE_ASM_TARGET_INCLUDE_PATH ${CMAKE_C_TARGET_INCLUDE_PATH})
The CMAKE_C_TARGET_INCLUDE_PATH stuff is missing in the file that is created by CLion. I believe that is the reason why it does not find the headers. Question is how do I tell CLion to create the CMAKE_C_TARGET_INCLUDE_PATH stuff?

I assume that your project structure is :
project root
├── CMakeLists.txt
├── Some source files
└── unity
└── unity_fixture.h
If you use CMake to include files :
set(INCLUDE_DIR ./unity)
include_directories(${INCLUDE_DIR})
Your include must be : #include <unity_fixture.h>
Or you can use without using CMake to include directories : #include "unity/unity_fixture.h"

Related

How to specify the main class (in the root directory) for Mill to run?

I am new to the sbt and mill, and I am practicing to use both tool to build the chisel (scala project). View this github repo as a reference, I am wondering to know how to write the mill-version build.sh in that repo.
Here is my directory structure
─ chisel-template (root directory / projects directory)
├── build.sc
├── build.sh
├── src
| └─main
| └─scala
| └─lab1
| └─Mux2.scala
└── _temphelper.scala
What the build.sh do is preparing a boilerplate as main function in the root directory to make compile and run process much easier, and it's sbt version. I'm curious that why sbt can detect the main function (_temphelper.Elaborate) even it's not in the src/main directory. And when I change to use Mill, Mill can't detect the _temphelper.scala at all, unless I move the file to root/src/main. Is there settings that can make Mill do what sbt can do?
I'm not sure whether this issue is related to...
altering the sourceDirectories in sbt and chiselMoudule.sources in Mill. Any advice is welcome.
modify the millSourcePath to realize my request.
My quetions is What setting should I do to make mill can detect the main class that be in the root directory?
This is because sbt is including any Scala files it finds in the project root directory as sources files, unless told otherwise.
In contrast, Mill will only use the source files found under whatever directories are specified with sources. As a consequence, you may want to add the project root directory as source directory, but I strongly advice to do not so.
Best is to move the _temphelper.scala file either to one of the source directories or create a new dedicated directory, move the file there and add this directory to the sources like this:
object chiselModule extends CrossSbtModule // ...
{
def sources = T.sources {
super.sources() ++ Seq(PathRef(T.workspace / "your" / "new" / "directory"))
}
}

How to add an ESP-IDF library to an external library

I'm trying to add an external library into my project.
My projectstructure looks like this:
-project
-- main
--- main.c
--- displayfunctions.c (where i implement my Displayfunctions based on the library)
--- 2 other .c files which got nothing to do with my Display
--- CMakeLists.txt
-- components
--- displaylibrary
---- CMAKELists.txt
---- all displayrelevant librarys pngle.c fontx.c etc..
---- include
----- all corresponding header files pngle.h fontx.h etc.
my CMakeLists.txt file in project/components/displaylibrarys looks like this:
idf_component_register(SRCS "pngle.c" "decode_jpeg.c" "decode_png.c" "fontx.c" "ili9340.c"
INCLUDE_DIRS "include" )
include($ENV{IDF_PATH}/tools/cmake/project.cmake)
when i try to compile my project I get the following Error Message:
../components/Displaylibrarys/fontx.c:7:10: fatal error: esp_spiffs.h: No such file or directory #include "esp_spiffs.h"
so apparantly my compiler does not link the in my external library included esp-idf library with an actual esp-idf library. I tried it with this approach too
idf_component_register(SRCS "pngle.c" "decode_jpeg.c" "decode_png.c" "fontx.c" "ili9340.c"
INCLUDE_DIRS "include"
REQUIRES esp_spiffs)
but without a result. How should i properly tell my compiler that it knows this library?
The ESP-IDF build system works with components. Your library is a component, and so are many parts of the ESP-IDF library.
As part of the component approach, your component needs to declare what other components it depends on. That's what the REQUIRES clause is for.
You almost got it right except the the component is called spiffs instead of esp_spiffs.
idf_component_register(SRCS "pngle.c" "decode_jpeg.c" "decode_png.c" "fontx.c" "ili9340.c"
INCLUDE_DIRS "include"
REQUIRES spiffs)
I usually check the ESP-IDF components directory to figure out the correct name. The component and directory name are the same: https://github.com/espressif/esp-idf/tree/master/components

How to integrate Imebra v5 to a swift command line project

I'm trying to import Imebra into a basic swift 5 command line project using Xcode 12. I followed the official steps but I failed. I can summarise the whole structure:
The structure of the project is just
./
├── main.swift
├── Data
└── DX_0.dcm
├── Imebra
└── CMakeLists.txt
└── docs
└── examples
└── library
└── test
└── wrappers
└── build_imebra_macos
The main swift file is
// main.swift
import Foundation
print("Hello, Imebra!")
do {
let pDataSet = try ImebraCodecFactory.load(fromFile: "PathToDicomFileFromExecutable")
let pImage = try pDataSet.getImageApplyModalityTransform(0)
print("The image width is", pImage.width)
} catch {
print(error)
}
Following the documentation, I compile the library by going to the build_imebra_macos folder and running
build_imebra_macos % cmake -GXcode -DCMAKE_BUILD_TYPE=Release ..
build_imebra_macos % cmake --build . --config Release
The build is successful and the new folder Release has the dynamic library. Now in Xcode project of the CL Swift application, SwiftyImebra.xcodeproj, I followed the next instruction "open the target Build Settings and under “Swift Compiler/ObjectiveC Bridging Header” specify the path to imebra_location/wrappers/objectivec/include/imebraobjc/imebra.h.”, with Imebra_location changed to Imebra.
Then when I build I get the error
Showing All Messages
Undefined symbol: _OBJC_CLASS_$_ImebraCodecFactory
I'm new in Swift and I guess I need to specify somewhere in Xcode where the source or the dynamic library is. However, I am not sure about this either as we have generated a cpp dynamic library so this can only interact with objective-C (?). I apologise if this is a basic question...
In addition, I'd like to learn how to use Imebra as a static library with swift.
The imebra dynamic library must be added to the project.
Drag the imebra.dylib (generated into your build folder build_imebra_macos) into your project.
Additionally, specify the folder containing the dylib into the "Library search path" in the compiler options.

What should be in the Cargo.toml file at the root of the workspace so that Visual Studio Code supports all features?

Visual Studio Code says:
A Cargo.toml file must be at the root of the workspace in order to
support all features
However I did not find what should be in Cargo.toml file located in the workspace root. Is it common for all project subdirectories?
I have read the chapter Hello, Cargo! of the documentation, but it only speaks about the Cargo.toml files within the project directory.
By experimenting, I have found out that the file with only one line [workspace] makes the VS Code note go away, but now every time I set up a new project it nags me about the fact that this project is not mentioned in the members array within this "workspace" Cargo.toml
Visual Studio Code directory structure is as follows
workspace
|
---> project1
|
---> project2
the cargo new project3 generates Cargo.toml within newly created project3 directory, but Visual Studio Code expects another Cargo.toml within the workspace directory itself.
This is covered in chapter 14 of the book, section 3. The Cargo.toml at the root of a Cargo workspace should explicitly contain its member projects in the members property. Note that this is exactly what the IDE was advising you to do.
[workspace]
members = [
"project1",
"project2",
]
Quoting:
Next, in the add directory, we create the Cargo.toml file that will configure the entire workspace. This file won’t have a [package] section or the metadata we’ve seen in other Cargo.toml files. Instead, it will start with a [workspace] section that will allow us to add members to the workspace by specifying the path to our binary crate; in this case, that path is adder:
Filename: Cargo.toml
[workspace]
members = [
"adder",
]
Next, we’ll create the adder binary crate by running cargo new within the add directory:
$ cargo new --bin adder
Created binary (application) adder project
At this point, we can build the workspace by running cargo build. The files in your add directory should look like this:
├── Cargo.lock
├── Cargo.toml
├── adder
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── target
Another example of this in the wild is serde (Cargo.toml).
The Cargo documentation provides additional details on the members field, including that path dependencies are included automatically.
The root crate of a workspace, indicated by the presence of [workspace] in its manifest, is responsible for defining the entire workspace. All path dependencies residing in the workspace directory become members. You can add additional packages to the workspace by listing them in the members key. Note that members of the workspaces listed explicitly will also have their path dependencies included in the workspace. [...]
In this case, no path dependencies nor members were stated in the root Cargo project, leading to the sub-directories not being regarded as workspace members.
As a workaround, I was able to create a top-level Cargo.toml with the following content:
[workspace]
members = [
"./*/src/..",
]
With this, I can create new projects under the workspace without explicitly updating the top-level Cargo.html.
As a note, the more obvious globs like "*", "./*" and "*/" do not work because the resulting matches must be directories with Cargo.toml files, and these globs match more than that (including "./target/", for example). The path I came up with results in the right subset (at least in the basic, typical case).

How to link my .h and .c files in the same project but different directory using CMake

I'm currently working on an embedded C project in Eclipse, cross-compiling to an M4 Cortex target. This project will create 3 separate executable files: apple.hex, orange.hex, and pear.hex. The "apple" source directory compiles, builds, and links without any dependencies on "orange" or "pear". The "orange" source directory also compiles, builds, and links without any dependencies.
However, "pear" needs to access numerous .h and .c assets from "orange". I've had many attempts at getting my CMakeLists.txt to "find" and "link" the code from "orange" to "pear", but to no avail.
Here is my current CMakeLists.txt file:
cmake_minimum_required(VERSION 3.0)
file(GLOB LD_FILE *gcc_nrf52.ld)
set(MY_APP_DIR ${CMAKE_SOURCE_DIR}/apps/orange)
create_application(
NAME
"pear"
PLATFORM
target
INCLUDE_DIRS
./
${MY_APP_DIR}
LINKER_SCRIPT
${LD_FILE}
SOURCES
${MY_APP_DIR}/foo.c
${MY_APP_DIR}/foo_bar.c
main.c
LIBRARIES
SomeLib_1
SomeLib_2
SomeLib_3
)
However, the compiler keeps complaining, saying that it cannot find "foo.h" and "foo_bar.h".
1) Do I need to separately create a static library in orange in order to access it in pear?
2) If I don't need to create a static library to access orange from pear, how do I link orange to pear?
3) I cannot find where CMake places the object files. Where are they?
This project is all under a single makefile.
Any help would be greatly appreciated, thanks!
I was able to fix my directory issues so that all of the include directories in ${MY_APP_DIR} are being linked into "Pear". However, a new issues has arisen. The linker cannot find the map file needed to create the executable image:
/usr/local/Caskroom/gcc-arm-embedded/5_4-2016q3,20160926/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld: cannot open map file /Users/admin/Github/target/apps/pear/pear.map: No such file or directory.
I'm not sure why a map find isn't being created. Is the linker (ld) still missing files?
I'll try to answer your questions
You are not linking your libraries to your target.
You need something like:
$target_link_libraries(yourtarget yourlibraries)
after your add_executable command.
3) I cannot find where CMake places the object files. Where are they?
CMake puts all of its outputs in the build tree by default, so unless you are liberally using ${CMAKE_SOURCE_DIR} or ${CMAKE_CURRENT_SOURCE_DIR} in your cmake files, you should find the output files in the folder where your CMakeLists.txt file is.