Comments (2)
Good idea. Butido currently lacks the concept of distros (s. also #185 (comment)) but IMO it's quite essential for a proper distro/OS independent package build tool to support distro/OS specific configurations.
I'm not sure how to best address this though. Distro specific build/runtime deps should be fairly easy to achieve but I wonder if that's enough as we might also need different configure/compile/etc. flags (depending on the distro), which would require a generic solution (that could ideally be used everywhere - but I don't (immediately) see a good solution for that with TOML files). However, as long as the only use case is to take a dependency from butido's package repo or the system, it should be possible to ignore the rest (although it'd make sense to then make the OS/system packages conditional as well).
Any concepts/ideas/suggestions what the usage should look like (TOML example)?
It might make sense to use regex patterns/matching to avoid potentially long lists.
We could theoretically also match against the container image names instead of additional OS information that would have to be added first.
Maybe something roughly like this?:
[docker]
images = [
{ name = "local:sles15-default", short_name ="sles15" },
{ name = "local:deb11-default", short_name ="deb11" },
{ name = "local:deb12-default", short_name ="deb12" },
]
---
[dependencies]
runtime = ["foo =1.2.3"]
build = [("example =1.2.3", "deb*") ("bar =1.2.3", "sles15")]
I haven't thought much about the design yet, that's just the first thing that came to mind. Unfortunately TOML doesn't support tuples so we have to think of a proper design anyway (the tuples could be replaced with inline tables, which should make it easier to read and understand (for outsiders/newcomers) but the "code" would be longer (character count) and probably more annoying to write).
We should also try to keep the design backward-compatible (in my draft above "foo =1.2.3"
could expand to ("foo =1.2.3", "*")
so that users aren't required to change almost all of their files in the packages repo.
from butido.
Distro specific build/runtime deps should be fairly easy to achieve but I wonder if that's enough as we might also need different configure/compile/etc. flags (depending on the distro), which would require a generic solution (that could ideally be used everywhere - but I don't (immediately) see a good solution for that with TOML files).
Brief update: Due to additional customization requirements and the constraints of TOML, we decided to try this out via a preprocessor (and if it works out well, we could theoretically integrate (parts of) it into butido).
from butido.
Related Issues (20)
- misleading error when not called from top-level package directory
- butido tree-of does not distinguish between build and runtime dependencies HOT 2
- option/flag to filter output of "butido db jobs" on used image HOT 2
- SYS_BUILD_DEPENDS_RH8 vs. build = ["example = 1.2.3"] HOT 2
- config.toml versioning decoupled from butido version
- warn if a phase is used without [phases] section HOT 1
- remove unwanted trace output
- silently create release stores (if not present yet)
- /script does not contain every information it uses (environment variable, complete submit line, ...) HOT 1
- Warn/Error out if the downloaded files are html
- Switch from bors-ng to the GitHub pull request merge queue (public beta) HOT 3
- [sources.src] url=nosource for metapackages HOT 1
- make butido aware of metapackages
- Idea: Reproducible-ish builds
- error on dependency names startint with numerals HOT 1
- option to make "error on other task" not fatal
- trigger 'source verify' every time after 'source download'
- butido tree-of --dot
- butido tree-of --serial-buildorder
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from butido.