pedrolamarao / gradle-metal Goto Github PK
View Code? Open in Web Editor NEWGradle plugins to compile "bare metal" projects
License: GNU General Public License v3.0
Gradle plugins to compile "bare metal" projects
License: GNU General Public License v3.0
Currently, gradle-metal supports LLVM tools only.
Let us support MSVC tools also.
Tasks:
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.