Assembler sources

[pedrolamarao]

Is perhaps someone else trying to add assembler sources to a Nokee project?

Gradle has an old assembler plugin which adds asm source sets and does whatever it does.

I am studying Nokee to try and contribute a new plugin but am advancing very slowly.

[pedrolamarao]

This is our current solution:

import dev.nokee.platform.cpp.CppLibrary
import dev.nokee.platform.nativebase.StaticLibraryBinary
import dev.nokee.platform.nativebase.tasks.internal.CreateStaticLibraryTask

plugins { base }

abstract class AsmExtension
{
    abstract val source : ConfigurableFileCollection;
}

val asm = project.extensions.create<AsmExtension>("asm")

project.extensions.configure<CppLibrary> {
    binaries.configureEach {
        if (this is StaticLibraryBinary) {
            val createTask = createTask.get()
            if (createTask is CreateStaticLibraryTask) {
                asm.source.asFileTree.forEach { asmSource ->
                    val asmTask = project.tasks.register<Assemble>("asm-${name}-${asmSource.hashCode()}") {
                        assemblerArgs = emptyList()
                        objectFileDir = file("${buildDir}/asm/main")
                        source(asmSource)
                        targetPlatform.set(createTask.targetPlatform)
                        toolChain.set(createTask.toolChain)
                    }
                    createTask.source(asmTask.get().outputs.files.asFileTree)
                }
                createTask.doLast { createTask.source.files.forEach { logger.lifecycle("${name}: ${it}") } }
            }
        }
    }
}

[lacasseio]

The Nokee model is still not very kind to ad-hoc domain objects for two major reasons: 1) discovery and 2) proper hierarchy. I'm aware of some gaps in the discovery but if you don't intend to call the task directly, e.g. from the command line, then discovery isn't much of an issue. There may be some TaskProvider mutation issues as Gradle don't like nested registration of task which makes sense for a flat hierarchy that we abandoned a long time ago so we still have some path that can result in a mutation error from Gradle. I actually closed one of them today.

As for the proper hierarchy, there are two ways to deal with this: 1) we ignore hierarchy and push the responsibility to the user or 2) we provide intermediate modelling that abstracts the hierarchy for the user. I experimented with both and I still can't exactly decide. A pseudo code of the first solution would look like this:

library {
    // View#whenElementKnown would call back using KnownDomainObject which is similar to provider but doesn't allow `get()`
    // The action is called as soon as the binaries are known to Nokee
    binaries.whenElementKnown(StaticLibraryBinary) {
        def assembleTask = project.tasks.register("assemble${it.name.capitalize()}", Assemble) { ... }
        it.configure {
            createTask.configure { it.source(assembleTask.flatMap { it.objectFiles } } // Not sure if there is object files on Assemble task but there should be one :-)
        }
    }
}

The intermediate model approach would look like the following:

library {
    // View#whenElementDiscovered would call back using ModelObject which is centered around the model entity for a specific projection (domain object)
    // The action is called when the binary are discovered
    binaries.whenElementDiscovered(StaticLibraryBinary) {
        def assembleTask = it.newElement("assemble", Assemble).configure { ... }
        it.configure {
            createTask.configure { it.source(assembleTask.flatMap { it.objectFiles } } // Not sure if there is object files on Assemble task but there should be one :-)
        }
    }
}

As you can see both approach are similar, the first one is closer to what vanilla Gradle looks like. The second is very similar but the underlying hierarchy is carried over.

The previous example focus on ad-hoc configuration closer to vanilla Gradle, meaning we create the task we need and everything is peachy. On the modelling side, we should instead use the LanguageSourceSet interface to provide a more standalone/composable assembler support. The LanguageSourceSet is roughly equivalent to converting assembler sources to object files (in this scenario). The added bonus is the allowing to group the incoming dependencies that assembly language may need as well as some other configuration like _source compatibility. So in theory, an asm source set should be provided to the variant which we can then wire the object files to the create or link task. If a user simply wants to compile assembly sources without creating a static library or something else, they can just create the (hypothetical) AssemblySourceSet and all the compile task, configuration, properties would be created.

How can plugin author extend Nokee to provide such support? That is still an open question. Internally, we use the Universal Model for this but we currently feel it should be an implementation detail to Nokee which means any extensions should be done via vanilla Gradle APIs. In theory, LanguageSourceSet should be exposed via an ExtensiblePolymorphicDomainObjectContainer so it would be just a matter of registering the right factory and implementing the correct interface. However, even when writing this, I'm seeing an issue where the compile Task and incoming Configuration would be nested under the LanguageSourceSet which is the reason for the Universal Model.

I think we should build a sample (no need to be fully buildable, just the sources would be enough) so we can work through any APIs that we would need to supply for such an extension. We will most likely provide assembler support out-of-the-box but it's a good exercise to ensure we provide the correct APIs to the users.

Do you think you can provide a small sample to demonstrate this? It doesn't really need to target all OS given that modelling is a bit abstract. However, I remember being a difference between GCC/Clang and MSVC which would be great to cover.

[pedrolamarao]

I will study your comments and attempt to provide an AsmSourceSet in an independent plugin. I will need assembler support in a project soon.

[pedrolamarao]

Kotlin script support with code completion in the IDE helps a lot

[lacasseio]

Given your expertise in Kotlin DSL ;-) If there is anything strange or that could be improved on the Nokee side to make Gradle's configuration more idiomatic, don't hesitate to raise issues. I would need some extended background as I'm not a Kotlin expert and I, unfortunately, don't plan on becoming one. My focus has been mostly around Groovy DSL, however, I want to offer equal opportunity in both DSL.

[pedrolamarao]

Oh, Gradle and Nokee are pretty idiomatic, in my opinion. It is the IDE that help too little. At least, I can't get any useful code completion or "go to implementation" from Intellij with Groovy scripts.