pedrolamarao / gradle-metal Goto Github PK

Currently, gradle-metal supports LLVM tools only.

Let us support MSVC tools also.

Tasks:

• acquire sources
• validate sources signature
• configure < gradle-metal cmake DSL
• make < gradle-metal cmake DSL
• discover cmake components
• publish outgoing elements

Currently, tasks will try to resolve the compiler tool every time with Metal.locateTool. Let us cache this discovery somehow, resisting the urge to "model" the entire toolchain.

Let us make the compile tasks cacheable.

Add a linker script language, linker script elements and dependencies, and feed linker scripts to the linker.

This should improve the definition of metal multiboot2 library.

In preparation for the great refactoring, let us reorganize our samples.

• asm-application
• asm-archive
• c-application
• c-archive
• cxx-application
• cxx-archive
• dependency-on-project
• dependency-on-build
• dependency-on-prebuilt
• dependency-transitivity
• polyglot-application
• polyglot-archive

Currently, gradle-metal does not configure the target machine, leaving it up to the toolset.

Let us allow the user to specify the target machine.

The ultimate goal is to allow projects capable of multiple target machines with a protocol to resolve the target machine for a certain build.

Allow configuring targets for which a task or component makes sense. Running lifecycle tasks such as test must update only dependencies that make sense for this target.

Currently, one is able to load a gradle-metal project in CLion via compile commands database.

Let us write plugins for full IDE support.

Export method locateTool used to find the tool executable file in the tools path. Metal will use this to locate GRUB and QEMU.

Export string providers that yield platform conventions, and apply them in internal tasks. Prebuilt projects may enjoy them as well -- see Metal googletest.

The original "psys" build system, based on nokee, allowed us to define custom targets.

This enabled us to define targets such as x86_32-elf-multiboot2, something that makes perfect sense for this project: a target that generates code for x86_32 and links an ELF Multiboot2 application. This top level target would configure compilation for i686-elf and would include a dependency on module multiboot2, perhaps even link the application as a module to a multiboot2 start main module.

We could still support such a system if we had some kind of target mapping, that would take the "top" target name and map that to compile target and link target names.

That would be immediately useful, since clang thinks it needs gcc to link target i686-elf and we must trick it to use lld by transforming that to i686-linux-elf. This transform is hard-coded in MetalLinkTask.

Ditto.

Enabling setting includable, importable etc. sources to be public or private.
Public sources will be configured as published elements, private will not.

Let us support build flavors such as debug and release. This is fundamentally about defining flavour specific options, such as -g or -O2.

• define an artifact set scheme, probably using classifiers for includables, importables, linkables etc.
• explode artifacts into some local cache
• add includables etc. on local cache to includable elements etc.

The task is supposed to not run for reason of NO-SOURCES, but it does have sources: we feed "main" objects into the "test" link task via SourceTask::source.

Apply these instructions: https://docs.gradle.org/current/userguide/custom_tasks.html#incremental_tasks

Ditto.

Let us prepare Gradle Metal for the configuration cache. Performance is not an issue at this time, but this seems an excellent way to keep the plugins up with best practices.

Currently, the only public dependency configuration is nativeImplementation, which is not transitive.

Add some kind of "api" dependency configuration for transitive dependencies.

Export a provider that yields the host target name, discovered from running clang -v, and apply that as default target.

This should allow filtering targets with no weird exceptions.

Allow configuring archive project test dependencies.

Do variant aware selection on a "target" attribute.

Pulling dependencies from repositories will not be pratical without target aware selection.

Support dependency substitution from included builds just like JVM projects.

Assemble shared libraries.

This should require adjustments on MetalLinkTask to accomodate Windows library.lib and library.so distinction.
Let us take the opportunity to also support library.pdb for all executable components.

Why not.

Drive a googletest application, producing JUnit test reports, which every CI knows how to consume.

Make so that archive cpp and ixx sources are public by default, while application`s are private by default.

Provide a way to easily define the "test" component wired to "main" sources.

Perhaps the conventional archive plugin should set this up.

The run task for this component must be wired to the test task.

In 2022 I left this message to the Carbon team in their Github discussion forum: carbon-language/carbon-lang#1522

Let be back my own standing by supporting Carbon language and tools in gradle-metal.

Consider this: an application component with a dependency on a (shared) library component with an api dependency on a (static) archive. Certainly the application must be configured to include the (static) archive's public headers. But should it also link with the archive? Maybe introduce something akin to "compileOnlyApi"?

The current design allows for a single project with any number of components, mixing applications and archives. After applying to project Metal and gaining initial experience, this design is too complicated for no benefit.

Let us redesign Gradle Metal for a single main component per project. There will be no component container for creating components. There will be a single application or archive top level DSL object at most.

Let us do a specialized project that generates a JAR archive with a shared library appropriately for JNI or FFI based JVM libraries.

At this time, gradle-metal uses LLVM tools from the environment PATH.

Let us allow the user to write a toolset specification with custom paths.

Provide DSL for configuring target specific sources.
It is enough to allow including sources by pattern.

Discover tools installed with Chocolatey.

For example, use cmake and ninja from Chocolatey.

Let us use Github Actions to publish the plugin, storing the authorization secrets appropriately.

Currently, gradle-metal supports LLVM tools only.

Let us support GCC tools also.