Embedded C: SCons -> Gradle

Help/Discuss
1

I just recently moved from Make to SCons, but it seems outdated, the Jenkins plugin is from 2011, so I decided to move on to Gradle.

In SCons I have the possibility to create my own builder, for example:

elf = Builder(action = Action(‘$LD $LDFLAGS -I ${MEMAREAS.get_dir()} $SOURCES -o $TARGET’, ‘$LINKCOMSTR’), suffix = ‘.elf’, src_suffix = ‘.o’)

Is this also possible with Gradle? I really stuck at this point.

Furthermore, existing targets in SCons like env.Object() does not seem to exist in Gradle. How is it possible to create a object file (.o)? They will be linked together later, and the resulting output files are then .elf and .hex files. I need them for my embedded device. I would appreciate any help.

Thanks in advance.

2

Finally found a solution with Exec Task.

What bothers me, trivial scripting functions like, take a value from the environment or from the command line, optionally check them and provide a helper message is in SCons a one liner.

vars.Add(PathVariable(‘CC’, ‘the C(++) compiler’, os.environ.get(‘CC’,‘’), PathVariable.PathIsFile))

In Gradle I just found:

def CC= project.findProperty(‘CC’) ?: “$System.env.CC”

Is that all? Gradle does not seem very user friendly for custom builds.

3

You are going against the grain… The idiomatic Gradle way is to use plugins for the bulk of your build logic. If you share more about your use-case, I am sure some people on this forum would be able to point you to the relevant plugins. Still, try this as a starting point: https://docs.gradle.org/4.0/userguide/native_software.html

If you want to define your own build logic, best do it as a plugin (requires some learning, but it is not much more difficult than writing a build and a lot more reusable). If your plugin looks like it may be useful to others, it is easy to publish it to https://plugins.gradle.org.

See http://tiny.cc/gradle-plugins-101, http://tiny.cc/gradle-build-evo

The exec task is good for one-off, but not really as a way to do everything.

Regarding the variables, Gradle defines its own namespace of “project variables” - these are different than java.lang.System properties and envars. A pattern I sometimes use is to default a project var to envar if not explicitly specified - then you don’t have to check all over the place and you get better maintainability and consistency. Avoid system properties if you can.

I hope this helps.