I have a version.h header file where I have the version of my application defined:
#define VERSION 0x0100
I would like to add it as a suffix to the output file. So instead of having myapp.elf I would like to have myapp_0100.elf. Is there a way to use symbols in the compilation options?
You can do the opposite. Define a variable in Eclipse and use it when compiling.
Go to the Project Properties-> C/C++ Build -> Build variables
Define a new variable blah with value 0100. Then in the build settings, depending on your project type you can pass the -DVERSION=${blah} to the compiler. It will define the symbol called VERSION with the value given.
Now in Project Properties-> C/C++ Build -> Setting choose the Build Artifact tab. In the artifact name you can set myapp_${blah}.elf. Again, if your project is non-CDT managed, you can pass this variable to the makefile in order it to process it instead.
Related
I am new to Meson so please forgive me if this is a stupid question.
Simple Version of the Question:
I want to be able to assign a dynamic version number to the meson project version at build time. Essentially meson.project_version()=my_dynamic_var or project( 'my_cool_project', 'c', version : my_dynamic_var') (which of course won't work).
I would rather not pre-process the file if I don't have to.
Some background if anybody cares:
My build system dynamically comes up with a version number for the project. In my case, it is using a bash script. I have no problem getting that version into my top level meson.build file using run_command and scraping stdout from there. I have read that using doing it this way is bad form so if there is another way to do this.. I am all ears.
I am also able to create and pass the correct -DPRODUCT_VERSION="<my_dynamic_var>" via add_global_arguments so I COULD just settle for that.. but I would like the meson project itself to carry the same version for the logs and so I can use meson.project_version() to get the version in subprojects for languages other than c/c++.
The short answer, as noted in comments to the question, appears to be no. There is no direct way to set the version dynamically in the project call.
However, there are some work arounds, and the first looks promising for the simple case:
(1) use meson rewriting capability
$ meson rewrite kwargs set project / version 1.0.0
Then obviously use an environment variable instead of 1.0.0.
(2) write a wrapper script which reads the version from the environment and substitutes it into your meson.build file in the project call.
(3) adopt conan.io and have your meson files generated.
(4) use build options. This option, while not as good as (1) might work for other work flows.
Here's how option (4) works.
create a meson_options.txt file in your meson root directory
add the following line:
option('version', type : 'string', value : '0.0.0', description : 'project version')
then create a meson.build file that reads this option.
project('my_proj', 'cpp')
version = get_option('version')
message(version)
conf_data = configuration_data()
conf_data.set('version', version)
When you go to generate your project, you have an extra step of setting options.
$ meson build && cd build
$ meson configure -Dversion=$BUILD_VERSION
Now the version is available as a build option, then we use a configuration_data object to make it available for substitution into header/source files (which you might want to get it into shared libraries or what not).
configure_file(
input : 'config.hpp.in',
output : 'config.hpp',
configuration : conf_data
)
And config.hpp.in looks something like this:
#pragma once
#include <string>
const static std::string VERSION = "#version#";
When we do the configure_file call, #version# will get substituted for the version string we set in the meson configure step.
So this way is pretty convoluted, but like I said, you may still end up doing some of it, e.g. to print copyright info and what not.
As of 0.60.3 you may directly assign version from run_command which means the following will work without any meson_options.txt.
project('randomName', 'cpp',
version : run_command('git', 'rev-parse', '--short', 'HEAD').stdout().strip(),
default_options : [])
In particular, it is also possible to assign the result of a bash script, simply invoke it instead of git.
I have problems with linking to a library called xyz.a in my Eclipse CDT MinGW project. Eclipse projects cannot find this library unless I rename it to libxyz.a.
I have added:
library path to project via Properties/C C++ General/Paths and Symbols/Library Paths.
library name to project via Properties/C C++ General/Paths and Symbols/Libraries. Library name I specified here is xyz, so it's without extesion. What should I specify here in order to successfully include xyz.a without having to rename it to libxyz.a?
Some info I found online:
How do I specify the libraries to be searched by the linker?
MinGW supports libraries named according to the "<name>.lib" and "<name>.dll" conventions, in addition to the normal "lib<name>.a" convention common on *nix systems. To include libraries named according to any of these conventions, simply add an associated "-l<name>" specification to the compiler command, ensuring it is placed after the name of the module in which the reference appears.
Note that, if the library is not found in any of the default library search paths, you may also need to insert an appropriate "-L<dir>" switch to specify its location; (it is recommended that you place the "-L<dir>" switch before the "-l<name>" specification which requires it).
Also note that the library names "lib<name>.a" and "lib<name>.lib" are not equivalent; if you have a library named according to the aberrant "lib<name>.lib" convention, it will not be found by an "-l<name>" specification -- if you cannot rename the library, you must use the form "-llib<name>" instead.
You can link a library called oddname - where oddname includes any file-extension - in Eclipse CDT like this:
Navigate in the project Properties -> C/C++ Build -> Settings
-> Tool Settings -> GCC C++ Linker -> Libraries.
In Libraries(-l) panel add :oddname
If necessary, in the Library search path(-L) panel add the path to
oddname
OK out
This setting will add the option -l:oddname to the generated GCC link
command. -l:filename is the form of the -l option signifying that
the conventional lib prefix and the {.so|.a} extension are not implied and that
filename is the actual filename of the library to be linked. Here is the documentation
The simplest option is to just add the library to the command line of GCC. To do this with CDT add the library (whatever name it is) to the Other object (under Project settings -> C/C++ Build -> GCC C Linker -> Miscellaneous)
Here is a screenshot where I added a library with the file name badname.a to the command line of GCC.
When the build runs, this is the resultant command line:
Invoking: GCC C Linker
gcc -o "SO" ./src/SO.o /home/me/workspace/SO/badname.a
Note: the disadvantage of the above solution is the whole library is included, not just the objects within it that are referenced. You can alternatively add any linker flags you want by adding them to the Linker flags box in the same dialog.
I am creating a library, which require some assembly level code.
I am using using NASM to write and integrate my .asm file.
Now the problem is, I already have a project created in VS13. Now I want to add and integrate an assembly level code to my project.
I have already added a .asm file in my source directory, but when I am trying to run my test case, the compiler is unable to find my assembly code.
I want to know how can I link my .asm file with my .c file.
Structure of my project:
->Project1(Generates a Library)
--->Source
----->File1.c
----->File2.c
----->nasm.asm
->Project2 (Test case to use the library and generate .exe)
-->Source
---->main.c
Now, nasm.asm binaries should get attached with the .lib generated by project1
and Project2 should able to access project1.lib
Apologize if question is bit unclear, its a bit complex for me to make it clear in written. Please let me know if you want any clarification or extra information.
Thanks a lot
For each of you assembly files:
Right click it in the Solution Explorer and choose Properties
Make sure the selected Configuration is either All Configurations or the configuration you are using (this bites me every time!)
In the Configuration Properties>General change the Item type to Custom Build Tool
From the Configuration Properties>Custom Build Tool>General set the following items:
Command Line. Use this as an example: nasm -fwin32 "%(FullPath)" -o %(Filename).obj
Outputs. This is necessary, VS check for this files. I usually use %(Filename).obj.
Link Objects. Yes. If you name your output files with obj extension they are automatically included in the link phase.
To check that you set everything right, select your assembly file, right click and choose Compile.
I have a build machine server I am maintaining which is using Makefiles infrastructure.
As part of that infrastructure, I'm passing a few arguments to the Makefile from the build machine (example: user, build-server name, and various build variables known only when compiling for a specific project).
Some of these variables are aggregated to the code using gcc -D directive
-DSOME_VAR=VAL
I've now been asked to migrate an Iar Project into my build system. That is not a problem in itself, only I can't find any way to introduce preprocessor defines using iarbuild.exe command line tool.
I guess I could use an existing H file and edit it before compiling (using sed for example), but that's an ugly hack I would rather avoid if I can.
How do I properly achieve this with IAR?
I recently solved this using a combination of option #2 and the -varfile argvarfile option to iarbuild.exe. For my case I am controlling the output of cpputest. I need easy to read outputs for IDE builds but junit formatted outputs for build server builds. Here's my setup as an example.
Create a global variable in the IDE. Tools->Configure Custom Argument Variables...
Select global tab. Create group JUNIT. Create variable USE_JUNIT. Set the value to 0.
In the Project->Options->C/C++ Compiler->Preprocessor section add an entry for
JUNIT_OUTPUT=$USE_JUNIT$
In the code use
#if JUNIT_OUTPUT == 1
#define FLAGS "-ojunit"
#else
#define FLAGS "-v"
#endif
Create a file called jUnitOut.txt and put the following into it.
<?xml version="1.0" encoding="iso-8859-1"?>
<iarUserArgVars>
<group active="true" name="JUNIT">
<variable>
<name>USE_JUNIT</name>
<value>1</value>
</variable>
</group>
</iarUserArgVars>
Call iarbuild.exe with the normal options plus -varfile jUnitOut.txt
Some observations
Regarding #1 you don't actually need to create a global variable but when you do IAR creates ...\AppData\Roaming\IAR Embedded Workbench\global.custom_argvars. This file must be present for iarbuild.exe to use the -varfile you provide. Also, you can create workspace variables as well. These are stored in a file in the local project directory. This file can be added to source control so global variables can be avoided. IDE builds use the global and workspace variables while iarbuild will use the -varfile
Regarding #4 I didn't find any documentation on how to format the argvarfile. So, I created a workspace variable in the IDE, found the file it created to store the variable and then cut/pasted from that file into my jUnitOut.txt
To my understanding iarbuild does not support passing such parameters directly.
There are two possibilities that were suggested by IAR support and that both work for me (using 7.40.2):
1) Use a preinclude file
Go to Project->Options->C/C++ Compiler->Preprocessor
Add a preinclude file (e.g. preinclude.h)
Now have your build script generate that preinclude file before starting iarbuild
2) Use "Defined symbols"
Go to Project->Options->C/C++ Compiler->Preprocessor
Add an option to "Defined symbols" and use environment variable, e.g. "SOMEVAR=$_SOMEVAL_$"
On the cmd line, set the environment variable, e.g. "set SOMEVAR=myvalue"
Run iarbuild
The 2nd method is little more elegant, but the build will fail if the environment variable is not set, so I'll probably go with the 1st method.
This may answer your question:
To see the command line parameters, enable the option IAR Embedded Workbench IDE > Tools > Options... > IDE Options > Messages > Show build messages > select 'All'.
which is part of the web page at:
http://supp.iar.com/Support/?Note=47884
Is there a way to make the Eclipse editor presume that a specific C header file has already been included, without having to #include it explicitly?
For example, how can we achieve:
#include "common_type_defs.h"
#include "special_type_defs.h" // Don't want to have to mention this header file
main()
{
common_type var1;
special_type var2;
.....
}
by writing only:
#include "common_type_def.h"
main()
{
common_type var1;
special_type var2; // Eclipse editor: "Symbol 'special_type' could not be resolved"
.....
}
without getting the Eclipse editor annotation error: "Symbol 'special_type' could not be resolved".
The reason is, the project uses a custom scripted build system. The special header files are added automatically by the build system, selected from different libraries. So the build succeeds.
I have added the special header folder to the include paths of the project. This allows me to hit [F3] and jump to the definition of "special_type". It is just that the editor flags an error.
I do not want to silence the error because I want to catch real errors.
Any suggestions?
Go to:
Project properties → C/C++ General → Preprocessor Include Paths, Macros etc. → Entries → GNU C
Select CDT User Setting Entries and than click Add button. Select Include File and enter your preprocessor pre-include file here.
Apply and rebuild indexer.
I am using Oxygen.1a Release (4.7.1a)
Do additional define in your build system and then:
#ifndef CUSTOMBUILDER
#include "special_type_defs.h" // Don't want to have to mention this header file
#endif
I ended up creating different "build configurations", for each build option of the build system. There I can add the background header files, as required.
One disadvantage is that I must maintain the different build configurations to mirror the build system: when new header files are added to the build system, the same files must also be added to the eclipse build configuration. So this solution will be unsuitable for big team projects where multiple people frequently change the included files because you could easily miss a file change or two. But it works well for small teams and infrequent changes.