Embedded C: SCons -> Gradle

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.

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.

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.