This message was deleted.

I understand the confusion and it’s not an ideal situation. Historically, the “old native build” (often refer as the software model) was the first implementation. When Gradle shifted away from the software model, the newer plugin

cpp-application

and

cpp-library

were introduce which are simpler but rely on the software model for the toolchain configuration (reuse over reimplementing). When I left Gradle, I started Nokee because my passion has always being native support in Gradle. Nokee is superior to the newer core plugins. As for the software model, Nokee still has some feature that we are missing, mainly around edge cases. In general, we should be able to make then work without much issues. Nokee is in full time development which is the advantage over the other native support. I’m working with Gradle to clear the confusion but at the moment, it’s a bit messy. 😞 There’s a fundamental difference between Make/Scons and Gradle. In Make/Scons, users focus on how the software is built. In Gradle, we focus on what is been built. In your example, what you are creating is an executable linked against a library all implemented in C which target TRICORE. With recent change in Nokee, it should be possible to achieve this. If you could point me to a working same in Make/SCons and the TASKING compiler (hopefully available freely), then I can create a demonstration on how it’s done. The reason why Gradle don’t simply allow users to specify the command line to execute relies in the fact that the command line can and will be different depending on the target. For example, building an executable for Linux, macOS or Windows all follow the same basic concept but the resulting command line will be different (picture Gcc/Clang vs MSVC). The idea is to abstract away how the command line looks and focus on what is been built. You can still modify the command line for each variant. It’s a same for dependencies. Regardless where your dependency comes from (built locally, prebuilt, 3rd-party package, system library, etc), it’s always the same. It’s some kind of artifact with a set of attributes.

Hello Daniel, Thank you so very much for the reply and for your offer of help. The Tasking compiler trial version is available at https://www.infineon.com/cms/en/tools/aurix-tools/Compilers/TASKING/ I am not sure what to provide you from the Make/SCons world. Would you prefer the configuration file or would you would prefer the full command line call for the executables? For now, please find a small snippet of the executables that we are referring to from the TASKING compiler suite.

class CtcAurix_TC27xx(Platform):
    def __init__(self, env):
        Platform.__init__(self, env)
        """
        Paths to executables used by this platform
        """
        # Path to the compiler suite bin folder
        bin_path = posixpath.join(env['TOOLSPATH'],'CTC_AURIX',env['TOOLVERSION'],'ctc','bin')
        # Path to the compiler executable
        self.CCPATH = posixpath.join(bin_path,'ctc.exe')
        # Path to the assembler executable
        self.ASMPATH = posixpath.join(bin_path,'astc.exe')
        # Path to the archiver executable
        self.ARPATH = posixpath.join(bin_path,'artc.exe')
        # Path to the linker executable
        self.LINKPATH = posixpath.join(bin_path,'ltc.exe')
        # Path to the MCS executables
        mcs_bin_path = posixpath.join(env['TOOLSPATH'],'CTC_AURIX',env['TOOLVERSION'],'cmcs','bin')
        # Path to the MCS compiler executable
        self.MCSCOMPPATH = posixpath.join(mcs_bin_path,'cmcs.exe')
        # Path to the MCS assembler executable
        self.MCSASPATH = posixpath.join(mcs_bin_path,'asmcs.exe')
        # Path to the c51 executables
        scr_bin_path = posixpath.join(env['TOOLSPATH'],'CTC_AURIX',env['TOOLVERSION'],'c51','bin')
        # Path to the SCR compiler executable
        self.SCRCOMPPATH = posixpath.join(scr_bin_path,'c51.exe')
        # Path to the SCR assembler executable
        self.SCRASPATH = posixpath.join(scr_bin_path,'as51.exe')

A typical command line looks like this. We perform a splitted compilation where in the C-file is first converted to assembly file and then assembled using an assembler to generate the object file.

c:\legacyapp/CTC_AURIX/6.2r1p2/ctc/bin/ctc.exe work\bsw\arch\arlib\bfx\bfx\pi\i\bfx_main.c --error-file=../log/err/bfx_main.c_err -g -OacefgIklmnopRsuvwy --eabi=DCfHnsW --immediate-in-code -t3 -F -N0 -Z0 -Y0 --core=tc1.6.2 --iso=99 --no-macs --switch=linear -f./includes.txt -Ic:\legacyapp/CTC_AURIX/6.2r1p2/ctc/include -o work\bsw\arch\arlib\bfx\bfx\pi\i\bfx_main.src

c:\legacyapp/CTC_AURIX/6.2r1p2/ctc/bin/astc.exe --error-file=../log/err/bfx_main.s_err -il --core=tc1.6.2 -f./includes.txt -Ic:\legacyapp/CTC_AURIX/6.2r1p2/ctc/include -o work\bsw\arch\arlib\bfx\bfx\pi\i\bfx_main.o work\bsw\arch\arlib\bfx\bfx\pi\i\bfx_main.src

We usually copy the installation package to our local machine and execute the build using the executables with-in the compiler suite. If you have a look at the SCons configuration file, you will see many executables getting used for the build, this is basically because other than the normal compilation, some C-files are specifically used for certain features like the XC800 Standby controller (SCR), and MCS/GTM timer module of AURIX TC3xx, and Peripheral Control Processor (PCP) and needs to be compiled with the relevant executables; Also link step is handled specially that these object files from the special C-files are to be linked with a separate argument in the linker command line call. Please let me know if you were expecting more information.

Is converting C to ASM then compile ASM to OBJ the usual way to compile or the toolchain can compile C to OBJ in one invocation? It is not impossible to do, simply unusual compared to other toolchain. For the two step process, we would probably consider ASM -> OBJ as the compile step and the C -> ASM as the source generation. The project would basically be an assembly language project but we can still map the C file so IDE take those into account (not the generated ASM).

Hello Daniel, Thank you for the reply. Regarding the 2 step compilation process (.c -> .src and .src -> .o), this has been the convention that we had followed for more than 8 years. The compiler can directly compile from (.c -> ,o) like any normal C compiler. When I joined the team about 8 years back, I asked our compiler team (we get our compilation command lines and arguments from a dedicated compiler team who deals with compiler validation) the same question (for the obvious reason of build time improvement), they gave me some reason(s) at that time which I do not fully remember now (If I remember correctly they mentioned some thing about the generated binary code out of the obj being much better optimized, but I could be wrong, I will get back to you on this). I think I understood what you are trying to say regarding the 2 step compilation process

Hmm, I see. It’s pretty interesting. The first thing that comes to mind is finding a composable way to model the files and their features/capabilities. I feel the most important aspect is ensuring that as files move along in the process, there are some information that needs to follow them to ensure 1) the right tools are selected and 2) they are now mixed in incompatible ways. The confident in how things were built, aka an auditable build manifest, would be very important. The second most important aspect is composition and testing of the build logic. There seems to be multiple competing features which between them create a mini-dependency graph in terms of what needs to be done in which order. Each of those needs to be tested individually and the composition needs to perform as expected or fail fast if it’s not expected. Let me have a second read on what you wrote, and look into the testing framework. I have a general idea, but would like to learn a bit more. It seems that most feature in Nokee are useful here, but I get the feeling there would be a need for a partial blank slate for some of the configuration. For example, I don’t see the user write the variant handling code, but each variant may differ wildly (the optimization process is most likely only require in release binaries vs debug binaries).

Hello Daniel, We have not yet made a final decision on which IDE will be used for the Gradle build for the users, but initial thought is to use Visual Studio Code. But this depends on the outcome of our Proof Of Concept and its acceptance by the internal super user community. We are already using Eclipse Buildship plugin to create custom Gradle plugins for the POC. We had 5 goals identified for POC (listed below). We have done the 4 (thanks to many Gradle community members who have helped Tom Gregory, James Justinic, Jendrik Johannes), native build is the one task pending. James (He is my mentor for the Gradle Fellowship program) is the member who recommended Nokee to me. • Chaining of build process(es) based on input and output file(s) • Incremental execution of build process(es) • Parallelization of build process steps. • Reuse of previously built artifacts - Build Cache mechanism • Support for C SW project builds