Defining new architectures for TargetMachine

[pedrolamarao]

Nokee 0.4 allows building for arbitrary targets by overloading, so to speak, TargetMachine.architecture:

    targetMachines.addAll(
        // #XXX: build on host for host
        machines.linux.x86_64,
        machines.windows.x86_64,
        // #XXX: build on host for x86_32-elf-multiboot2
        machines.linux.architecture("x86_32-elf-multiboot2"),
        machines.windows.architecture("x86_32-elf-multiboot2"),
        // #XXX: build on host for x86_64-elf-multiboot2
        machines.linux.architecture("x86_64-elf-multiboot2"),
        machines.windows.architecture("x86_64-elf-multiboot2"),
    )

This way, one convinces Nokee that the project is buildable, and Nokee builds with the appropriate toolchain, which is configured via model. The project is buildable on any host with an LLVM toolchain and there is no target operating system.

Upgrading to the latest 0.5 this construct ceases to compile because the attribute setter is no longer a member of TargetMachineBuilder. I have also noticed that the os setter is no longer a member of TargetMachineFactory.

What will be the recommended way to defne arbitrary TargetMachines in 0.5?

[lacasseio]

I'm not sure I fully follow the attribute and os setter. The TargetMachineFactory/TargetMachineBuilder pulled some legacy from the Gradle core with regards to "assuming" host when OS family or architecture are not defined. In the example you gave, you have the "legacy" default where the targetMachines already contains the host target machine (OS family and architecture). I say "legacy" here because it's a nice convenience for building but it becomes a problem when we realize the build is implicitly tied to the environment as "host target machine" means different things in different environments. Generally, for building software, it's not a big deal but it becomes a problem when publishing. Regardless, that doesn't seem to be the issue here.

Contrary to the software model where target platform could be defined and mutated however we wanted, the TargetMachine in Nokee are value objects, meaning immutable once created. It ensures the configuration cannot be rug pulled accidentally or on purpose which would cause strange errors to appear. Internally, we may have had setter for OS family and architecture in the past but those were most likely removed during the refactoring to support ad-hoc architecture and OS family. In the latest nightly, the mapping between the target machine and the target platform of toolChains in the model is a concatenation of the canonical OS family name and architecture name. The known canonical names are baked in for OS families and architectures. For unknown architecture, we use the exact name specified, i.e. x86_32-elf-multiboot2.

What you have defined in your example, should still be the way to define arbitrary TargetMachines in 0.5 and later. It's important to complete the declaration with the proper toolChains configuration in the model. We want to get rid of that but given that we already have clients using that model, we will most likely have to go through a deprecation cycle. For the short term, you will still need to use the toolChains model. In the future, we will use the Gradle dependency engine.

If there is anything that doesn't work, please provide a sample and I will have a look at it.

[pedrolamarao]

I will push an example to Github today.

[pedrolamarao]

Example project: https://github.com/pedrolamarao/nokee-toolchains

This project fails at configuration time when you update settings.gradle.kts changing nokee version from 0.4.0+ to 0.5.0+.

Error message:

e: C:\Users\Pedro\Code\nokee-toolchains\app\build.gradle.kts:9:18: Unresolved reference: os

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\Users\Pedro\Code\nokee-toolchains\app\build.gradle.kts' line: 9

* What went wrong:
Script compilation error:

  Line 9:         machines.os("host").architecture("-x86_64-elf-multiboot2")
                           ^ Unresolved reference: os

1 error

If instead of using the host dummy operating system name one goes via my original route with machines.windows.architecture("...") the error is similar:

e: C:\Users\Pedro\Code\nokee-toolchains\app\build.gradle.kts:9:26: Unresolved reference. None of the following candidates is applicable because of receiver type mismatch: 
public inline operator fun <T : Any, C : NamedDomainObjectContainer<TypeVariable(T)>> TypeVariable(C).invoke(configuration: Action<NamedDomainObjectContainerScope<TypeVariable(T)>>): TypeVariable(C) defined in org.gradle.kotlin.dsl
public operator fun <T> Closure<TypeVariable(T)>.invoke(): TypeVariable(T) defined in org.gradle.kotlin.dsl
public operator fun <T> Closure<TypeVariable(T)>.invoke(x: Any?): TypeVariable(T) defined in org.gradle.kotlin.dsl
public operator fun <T> Closure<TypeVariable(T)>.invoke(vararg xs: Any?): TypeVariable(T) defined in org.gradle.kotlin.dsl
public operator fun <V> Callable<TypeVariable(V)>.invoke(): TypeVariable(V) defined in org.gradle.kotlin.dsl
public operator fun <T, R> DeepRecursiveFunction<TypeVariable(T), TypeVariable(R)>.invoke(value: TypeVariable(T)): TypeVariable(R) defined in kotlin
public operator fun <T> Action<in TypeVariable(T)>.invoke(target: TypeVariable(T)): Unit defined in org.gradle.kotlin.dsl
public operator fun <T> NamedDomainObjectProvider<TypeVariable(T)>.invoke(action: TypeVariable(T).() -> Unit): Unit defined in org.gradle.kotlin.dsl
public operator fun ArtifactHandler.invoke(configuration: ArtifactHandlerScope.() -> Unit): Unit defined in org.gradle.kotlin.dsl
public operator fun DependencyConstraintHandler.invoke(configuration: DependencyConstraintHandlerScope.() -> Unit): Unit defined in org.gradle.kotlin.dsl
public inline operator fun <T> ExtraPropertiesExtension.invoke(initialValueProvider: () -> TypeVariable(T)): InitialValueExtraPropertyDelegateProvider<TypeVariable(T)> defined in org.gradle.kotlin.dsl
public operator fun <T> ExtraPropertiesExtension.invoke(initialValue: TypeVariable(T)): InitialValueExtraPropertyDelegateProvider<TypeVariable(T)> defined in org.gradle.kotlin.dsl
public operator fun <T> Spec<TypeVariable(T)>.invoke(arg: TypeVariable(T)): Boolean defined in org.gradle.kotlin.dsl
public inline operator fun TaskContainer.invoke(configuration: TaskContainerScope.() -> Unit): TaskContainer defined in org.gradle.kotlin.dsl

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\Users\Pedro\Code\nokee-toolchains\app\build.gradle.kts' line: 9

* What went wrong:
Script compilation error:

  Line 9:         machines.windows.architecture("-x86_64-elf-multiboot2")
                                   ^ Unresolved reference. None of the following candidates is applicable because of receiver type mismatch: 
                                       public inline operator fun <T : Any, C : NamedDomainObjectContainer<TypeVariable(T)>> TypeVariable(C).invoke(configuration: Action<NamedDomainObjectContainerScope<TypeVariable(T)>>): TypeVariable(C) defined in org.gradle.kotlin.dsl
                                       public operator fun <T> Closure<TypeVariable(T)>.invoke(): TypeVariable(T) defined in org.gradle.kotlin.dsl
                                       public operator fun <T> Closure<TypeVariable(T)>.invoke(x: Any?): TypeVariable(T) defined in org.gradle.kotlin.dsl
                                       public operator fun <T> Closure<TypeVariable(T)>.invoke(vararg xs: Any?): TypeVariable(T) defined in org.gradle.kotlin.dsl
                                       public operator fun <V> Callable<TypeVariable(V)>.invoke(): TypeVariable(V) defined in org.gradle.kotlin.dsl
                                       public operator fun <T, R> DeepRecursiveFunction<TypeVariable(T), TypeVariable(R)>.invoke(value: TypeVariable(T)): TypeVariable(R) defined in kotlin
                                       public operator fun <T> Action<in TypeVariable(T)>.invoke(target: TypeVariable(T)): Unit defined in org.gradle.kotlin.dsl
                                       public operator fun <T> NamedDomainObjectProvider<TypeVariable(T)>.invoke(action: TypeVariable(T).() -> Unit): Unit defined in org.gradle.kotlin.dsl
                                       public operator fun ArtifactHandler.invoke(configuration: ArtifactHandlerScope.() -> Unit): Unit defined in org.gradle.kotlin.dsl
                                       public operator fun DependencyConstraintHandler.invoke(configuration: DependencyConstraintHandlerScope.() -> Unit): Unit defined in org.gradle.kotlin.dsl
                                       public inline operator fun <T> ExtraPropertiesExtension.invoke(initialValueProvider: () -> TypeVariable(T)): InitialValueExtraPropertyDelegateProvider<TypeVariable(T)> defined in org.gradle.kotlin.dsl
                                       public operator fun <T> ExtraPropertiesExtension.invoke(initialValue: TypeVariable(T)): InitialValueExtraPropertyDelegateProvider<TypeVariable(T)> defined in org.gradle.kotlin.dsl
                                       public operator fun <T> Spec<TypeVariable(T)>.invoke(arg: TypeVariable(T)): Boolean defined in org.gradle.kotlin.dsl
                                       public inline operator fun TaskContainer.invoke(configuration: TaskContainerScope.() -> Unit): TaskContainer defined in org.gradle.kotlin.dsl

1 error

[lacasseio]

Sorry Pedro for not responding earlier, if there is another delay like this, don't hesitate to ping me directly. :-) The issue with changing the version from 0.4.0+ to 0.5.0+ is mainly due to a version scheme change that was supposed to be followed by an official release which hasn't happened yet. The latest versions is 0.4.x, any 0.5.0-<hash> versions pre-date all 0.4.x. The timeline is then 0.3.0 (GA), 0.4.0-<hash> (snapshot), 0.4.0 (GA), 0.5.0-<hash> (snapshot), 0.4.x-<timestamp>.<hash> (snapshot), 0.4.x (head)

I understand the confusion and I didn't want to have such a long gap between the version scheme change and the release. The goal is to move toward automatic patch GA releases, aka if all tests pass, then the version is production-ready. At the moment, all 0.4.x-<timestamp>.<hash> are automatically released on each commit (in the snapshot repository). The head release 0.4.x should release in the release repository but that part isn't done yet.

With that timeline in mind, the new os and architecture factory methods are available in the 0.4.x-* but not in 0.5.0-<hash> versions.

[pedrolamarao]

Oh, thanks!