16.10.1 build with say gcc -D what's the recommended method CFLAGS

1

Hi

I would like to set an app wide #define which legacy code can pick up (CFLAGS etc) .

In other systems stuff like the following GCC command line preprocessor option in a makefile does the job.

CFLAGS += -D_OPTION1

effectively #define _OPTION1 added to all the c source files.

Assuming I have some legacy code I want to reuse (unchanged) which is peppered with stuff like #if defined(_OPTION1) - what is the best the way to implement this (-D) in Legato ?

To remind me what this was all about in the future when I’ve forgotten I even asked the question

Cheers

John

2

Hi @johnofleek,

there is a --cflags option for mk tools.
I just realized that it’s not in the doc so we will fix that, but here is what the help says for mkapp:

Command line parameters
-C, --cflags,
(Multiple, optional) Specify extra flags to be passed to the C compiler.

-L, --ldflags,
(Multiple, optional) Specify extra flags to be passed to the linker when linking executables.

-X, --cxxflags,
(Multiple, optional) Specify extra flags to be passed to the C++ compiler.

-a, --append-to-version,
(Multiple, optional) Specify a suffix to append to the application version specified in the .adef file. Will automatically insert a ‘.’ between the .adef’s version string and any version strings specified on the command-line. Multiple occurences of this argument will be combined into a single string.

-b, --bin-pack
(Optional) Generate a binary-app package instead of a .update file. Binary-app packages can be used to distribute an application without its original source code. This binary app package file is intended to be included in a system definition (.sdef) file’s ‘apps:’ section in place of a .adef file.

-c, --component-search,
(Multiple, optional) (DEPRECATED) Add a directory to the source search path (same as -s).

-g, --generate-code
(Optional) Only generate code, but don’t compile, link, or bundle anything. The interface definition (include) files will be generated, along with component and executable main files and configuration files. This is useful for supporting context-sensitive auto-complete and related features in source code editors, for example.

-i, --interface-search,
(Multiple, optional) Add a directory to the interface search path.

-n, --dont-run-ninja
(Optional) Even if a build.ninja file exists, ignore it, delete the staging area, parse all inputs, and generate all output files, including a new copy of the build.ninja, then exit without running ninja. This is used by the build.ninja to to regenerate itself and any other files that need to be regenerated when the build.ninja finds itself out of date.

-o, --output-dir,
(Optional) Specify the directory into which the final, built application file(ready to be installed on the target) should be put.

-s, --source-search,
(Multiple, optional) Add a directory to the source search path.

-t, --target,
(Optional) Set the compile target (localhost|ar7).

-v, --verbose
(Optional) Set into verbose mode for extra diagnostic information.

-w, --object-dir,
(Optional) Specify the directory into which any intermediate build artifacts (such as .o files and generated source code files) should be put.

1 Like
3

Hi CoRfr

Many thanks - never thought of trying that. For future info to myself - mksys also has the same arguments

Are the tools expecting

-C “-D_OPTION1” -C “-D_OPTION2” …
or
-C “-D_OPTION1 -D_OPTION2 …”
or
maybe no " "
or something else?

?

Cheers

John

4

Hi @johnofleek,

I think both would work (ie you can provide multiple --cflags and it will aggregate them for you, or one long --cflags.

1 Like
5

Hi,

please note this is doable as well by adding a cflags section in CDEF file:

1 Like
6

Hi daav

Many thanks - if i’d thought to search for cflags in legato.io I would have found it.

But CoRfr’s answer made me think - is CoRfr’s suggested method more generic?

This is a total guess but is a cflags section supported in adef and sdef files? maybe also the others sections (say cxxflags)

7

Hi @johnofleek,

overall I would think it’s best to put it in .Xdef files as it allows you to have a build environment that is contained as much as possible in mk files and does not rely on some other tool (presumably make or a script) to provide the rights arguments to make it build.

It seems that as of 16.10 .sdef files are not supporting cflags, but in the release coming up they are (ie, 17.05).

Actually in that release our Makefile does a lot less since all the env variables that where being set in Makefiles have been moved to .sinc file (which are inclusion files for .sdefs).

1 Like
8

Hi CoRfr

Good point - I’d forgotten about DS. I’ve moved to using Kate with just a basic makefile to build. Everything sits in the current project directory but of course this wouldn’t necessarily be the case with fancier IDEs

9

I use the Component.cdef file to store the bits doing it this way i can build it as a system [sdef] or standalone outside devstudio …

cflags:
{
	-I${CURDIR}/legato/include
	-I${CURDIR}/include/drivers
	-I${CURDIR}/include/chips
	-I${CURDIR}/include/ciis_framework
	-I${CURDIR}/include/ciis_protocol
	-I${LEGATO_ROOT}/interfaces/audio
	-I${LEGATO_ROOT}/interfaces/modemService
	-I${LEGATO_ROOT}/interfaces/voiceCallService
	-DCOMBAPP_RELEASE_VERSION_MAJOR=1
	-DCOMBAPP_RELEASE_VERSION_MINOR=0
	-DCOMBAPP_RELEASE_VERSION_PATCH=0
}
ldflags :
{
	-lssl
	-lcrypto
}
1 Like
10

Also in 17.05 it will also be possible to have some logic in the .Xdef files, cf legato-af/defaultAirVantage.sinc at master · legatoproject/legato-af · GitHub for instance.

1 Like
11

Would you be able to provide what should I put into .cdef to have a define string?

e.g my program will do print(“%s”, std::string(MY_STRING) );

cflags:
{
-DMY_STRING=“some string”
}

btw. this example does not work…

12

I managed to send the needed string by putting it in line with mkapp like:

mkapp -X -DMY_STRING=\"some string\" -t wp77xx myadeffile.adef

But \ are forbidden in .cDef files, is there a way to overcome this?