#bmake — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #bmake, aggregated by home.social.
-
Hey all,
I think I mentioned before about resurrecting the hikari wayland compositor (https://hikari.acmelabs.space) which seems not to be in active development.
What I've done is spent quite a bit of time upgrading hikari from wlroots-0.15 -> wlroots-0.19.2
The efforts of this can be seen on this branch:
https://codeberg.org/thomasadam/hikari
On the `ta/wlroots-0.19` branch (the default branch for now in this repo).
If you'd like to use #got, see:
https://thomas.gothub.org/repos/?action=summary&path=hikari.git
This will be kept in sync with codeberg.
I think seems seem mostly working. Testing welcome though!
In addition to upgrading the wlroots version, I've also added the option to use #meson instead of #bmake
Any problems, file an issue on the repo, or speak to me directly.
Unofficially for now, I'm also lurking in the IRC #hikari channel on libera.chat, if that's more convenient.
-
Hey all,
I think I mentioned before about resurrecting the hikari wayland compositor (https://hikari.acmelabs.space) which seems not to be in active development.
What I've done is spent quite a bit of time upgrading hikari from wlroots-0.15 -> wlroots-0.19.2
The efforts of this can be seen on this branch:
https://codeberg.org/thomasadam/hikari
On the `ta/wlroots-0.19` branch (the default branch for now in this repo).
If you'd like to use #got, see:
https://thomas.gothub.org/repos/?action=summary&path=hikari.git
This will be kept in sync with codeberg.
I think seems seem mostly working. Testing welcome though!
In addition to upgrading the wlroots version, I've also added the option to use #meson instead of #bmake
Any problems, file an issue on the repo, or speak to me directly.
Unofficially for now, I'm also lurking in the IRC #hikari channel on libera.chat, if that's more convenient.
-
Hey all,
I think I mentioned before about resurrecting the hikari wayland compositor (https://hikari.acmelabs.space) which seems not to be in active development.
What I've done is spent quite a bit of time upgrading hikari from wlroots-0.15 -> wlroots-0.19.2
The efforts of this can be seen on this branch:
https://codeberg.org/thomasadam/hikari
On the `ta/wlroots-0.19` branch (the default branch for now in this repo).
If you'd like to use #got, see:
https://thomas.gothub.org/repos/?action=summary&path=hikari.git
This will be kept in sync with codeberg.
I think seems seem mostly working. Testing welcome though!
In addition to upgrading the wlroots version, I've also added the option to use #meson instead of #bmake
Any problems, file an issue on the repo, or speak to me directly.
Unofficially for now, I'm also lurking in the IRC #hikari channel on libera.chat, if that's more convenient.
-
Hey all,
I think I mentioned before about resurrecting the hikari wayland compositor (https://hikari.acmelabs.space) which seems not to be in active development.
What I've done is spent quite a bit of time upgrading hikari from wlroots-0.15 -> wlroots-0.19.2
The efforts of this can be seen on this branch:
https://codeberg.org/thomasadam/hikari
On the `ta/wlroots-0.19` branch (the default branch for now in this repo).
If you'd like to use #got, see:
https://thomas.gothub.org/repos/?action=summary&path=hikari.git
This will be kept in sync with codeberg.
I think seems seem mostly working. Testing welcome though!
In addition to upgrading the wlroots version, I've also added the option to use #meson instead of #bmake
Any problems, file an issue on the repo, or speak to me directly.
Unofficially for now, I'm also lurking in the IRC #hikari channel on libera.chat, if that's more convenient.
-
Hey all,
I think I mentioned before about resurrecting the hikari wayland compositor (https://hikari.acmelabs.space) which seems not to be in active development.
What I've done is spent quite a bit of time upgrading hikari from wlroots-0.15 -> wlroots-0.19.2
The efforts of this can be seen on this branch:
https://codeberg.org/thomasadam/hikari
On the `ta/wlroots-0.19` branch (the default branch for now in this repo).
If you'd like to use #got, see:
https://thomas.gothub.org/repos/?action=summary&path=hikari.git
This will be kept in sync with codeberg.
I think seems seem mostly working. Testing welcome though!
In addition to upgrading the wlroots version, I've also added the option to use #meson instead of #bmake
Any problems, file an issue on the repo, or speak to me directly.
Unofficially for now, I'm also lurking in the IRC #hikari channel on libera.chat, if that's more convenient.
-
As you can see the build process is smooth, the execution is blazingly fast. What more could I ask for?
#programming #technology #BSD #netBSD #metaOS #microVM #networking #qemu #host #bmake #curl #sshd #Linux
-
As you can see the build process is smooth, the execution is blazingly fast. What more could I ask for?
#programming #technology #BSD #netBSD #metaOS #microVM #networking #qemu #host #bmake #curl #sshd #Linux
-
As you can see the build process is smooth, the execution is blazingly fast. What more could I ask for?
#programming #technology #BSD #netBSD #metaOS #microVM #networking #qemu #host #bmake #curl #sshd #Linux
-
As you can see the build process is smooth, the execution is blazingly fast. What more could I ask for?
#programming #technology #BSD #netBSD #metaOS #microVM #networking #qemu #host #bmake #curl #sshd #Linux
-
As you can see the build process is smooth, the execution is blazingly fast. What more could I ask for?
#programming #technology #BSD #netBSD #metaOS #microVM #networking #qemu #host #bmake #curl #sshd #Linux
-
The mighty world of BSD
Playing with again smolBSD, a fantastic metaOS system that I talked about a few weeks ago.
I'm a newbie, a greenhorn, when it comes to meta-operating systems built on top of NetBSD.I am very eager to learn by doing, making mistakes in the process, correcting and feel the warmth of the BSD community, who is happy to correct, esp when I show that I read the docs after making the mistakes
The journey is fantastic, the learning process is fun. microVM's are amazing. I've registered 11ms boot times on this small machine with a few CPU cores (and 40GB RAM). The fun is endless
#programming #technology #BSD #netBSD #metaOS #microVM #networking #qemu #host #bmake #curl #sshd #Linux
-
The mighty world of BSD
Playing with again smolBSD, a fantastic metaOS system that I talked about a few weeks ago.
I'm a newbie, a greenhorn, when it comes to meta-operating systems built on top of NetBSD.I am very eager to learn by doing, making mistakes in the process, correcting and feel the warmth of the BSD community, who is happy to correct, esp when I show that I read the docs after making the mistakes
The journey is fantastic, the learning process is fun. microVM's are amazing. I've registered 11ms boot times on this small machine with a few CPU cores (and 40GB RAM). The fun is endless
#programming #technology #BSD #netBSD #metaOS #microVM #networking #qemu #host #bmake #curl #sshd #Linux
-
The mighty world of BSD
Playing with again smolBSD, a fantastic metaOS system that I talked about a few weeks ago.
I'm a newbie, a greenhorn, when it comes to meta-operating systems built on top of NetBSD.I am very eager to learn by doing, making mistakes in the process, correcting and feel the warmth of the BSD community, who is happy to correct, esp when I show that I read the docs after making the mistakes
The journey is fantastic, the learning process is fun. microVM's are amazing. I've registered 11ms boot times on this small machine with a few CPU cores (and 40GB RAM). The fun is endless
#programming #technology #BSD #netBSD #metaOS #microVM #networking #qemu #host #bmake #curl #sshd #Linux
-
The mighty world of BSD
Playing with again smolBSD, a fantastic metaOS system that I talked about a few weeks ago.
I'm a newbie, a greenhorn, when it comes to meta-operating systems built on top of NetBSD.I am very eager to learn by doing, making mistakes in the process, correcting and feel the warmth of the BSD community, who is happy to correct, esp when I show that I read the docs after making the mistakes
The journey is fantastic, the learning process is fun. microVM's are amazing. I've registered 11ms boot times on this small machine with a few CPU cores (and 40GB RAM). The fun is endless
#programming #technology #BSD #netBSD #metaOS #microVM #networking #qemu #host #bmake #curl #sshd #Linux
-
The mighty world of BSD
Playing with again smolBSD, a fantastic metaOS system that I talked about a few weeks ago.
I'm a newbie, a greenhorn, when it comes to meta-operating systems built on top of NetBSD.I am very eager to learn by doing, making mistakes in the process, correcting and feel the warmth of the BSD community, who is happy to correct, esp when I show that I read the docs after making the mistakes
The journey is fantastic, the learning process is fun. microVM's are amazing. I've registered 11ms boot times on this small machine with a few CPU cores (and 40GB RAM). The fun is endless
#programming #technology #BSD #netBSD #metaOS #microVM #networking #qemu #host #bmake #curl #sshd #Linux
-
Ever considered #bmake as a general purpose programming language? Here's FizzBuzz!
https://codeberg.org/sjmulder/bmake-toys/src/branch/master/fizzbuzz.mk
-
Ever considered #bmake as a general purpose programming language? Here's FizzBuzz!
https://codeberg.org/sjmulder/bmake-toys/src/branch/master/fizzbuzz.mk
-
Ever considered #bmake as a general purpose programming language? Here's FizzBuzz!
https://codeberg.org/sjmulder/bmake-toys/src/branch/master/fizzbuzz.mk
-
Ever considered #bmake as a general purpose programming language? Here's FizzBuzz!
https://codeberg.org/sjmulder/bmake-toys/src/branch/master/fizzbuzz.mk
-
Ever considered #bmake as a general purpose programming language? Here's FizzBuzz!
https://codeberg.org/sjmulder/bmake-toys/src/branch/master/fizzbuzz.mk
-
It's always nice when you find some obscure feature that happens to be the only way around a thorny problem.
Today that was the "::=str" feature in #bmake, for which the manual page even states "This modifier and its variations are useful in obscure situations such as...".
I needed to lazily evaluate the output of a command, but also have that output shared across other shell instances for the same target. Without ::=str I don't think there was any other way around the problem.
-
It's always nice when you find some obscure feature that happens to be the only way around a thorny problem.
Today that was the "::=str" feature in #bmake, for which the manual page even states "This modifier and its variations are useful in obscure situations such as...".
I needed to lazily evaluate the output of a command, but also have that output shared across other shell instances for the same target. Without ::=str I don't think there was any other way around the problem.
-
It's always nice when you find some obscure feature that happens to be the only way around a thorny problem.
Today that was the "::=str" feature in #bmake, for which the manual page even states "This modifier and its variations are useful in obscure situations such as...".
I needed to lazily evaluate the output of a command, but also have that output shared across other shell instances for the same target. Without ::=str I don't think there was any other way around the problem.
-
It's always nice when you find some obscure feature that happens to be the only way around a thorny problem.
Today that was the "::=str" feature in #bmake, for which the manual page even states "This modifier and its variations are useful in obscure situations such as...".
I needed to lazily evaluate the output of a command, but also have that output shared across other shell instances for the same target. Without ::=str I don't think there was any other way around the problem.
-
It's always nice when you find some obscure feature that happens to be the only way around a thorny problem.
Today that was the "::=str" feature in #bmake, for which the manual page even states "This modifier and its variations are useful in obscure situations such as...".
I needed to lazily evaluate the output of a command, but also have that output shared across other shell instances for the same target. Without ::=str I don't think there was any other way around the problem.
-
@mpts @lobocode I can't fully agree. "Make" is declarative by nature, and a fully declarative Makefile contains nothing but variable expansions and rules with recipes. I *would* agree that #bmake makes it easier to write such a Makefile in many cases for its powerful expansion modifiers (some of which you can't even simulate with gmake's custom functions, like substitutions using regular expressions). But OTOH, it also makes some "procedural" style easier by e.g. providing a "for" loop that runs at parse time (not available in #gmake).
That said, "!=" is a poor replacement for $(wildcard ): "!=" also runs at parse time, $(wildcard ) OTOH is a function only executed when needed for expansion. #bmake offers the "${:!...!}" expansion that would be a better match here (still with the drawback of having to call some external tool of course).
Of course, any "if" (and similar) forces immediate expansion of its arguments in both make flavors, therefore breaking the "pure" declarative style.
-
@mpts @lobocode I can't fully agree. "Make" is declarative by nature, and a fully declarative Makefile contains nothing but variable expansions and rules with recipes. I *would* agree that #bmake makes it easier to write such a Makefile in many cases for its powerful expansion modifiers (some of which you can't even simulate with gmake's custom functions, like substitutions using regular expressions). But OTOH, it also makes some "procedural" style easier by e.g. providing a "for" loop that runs at parse time (not available in #gmake).
That said, "!=" is a poor replacement for $(wildcard ): "!=" also runs at parse time, $(wildcard ) OTOH is a function only executed when needed for expansion. #bmake offers the "${:!...!}" expansion that would be a better match here (still with the drawback of having to call some external tool of course).
Of course, any "if" (and similar) forces immediate expansion of its arguments in both make flavors, therefore breaking the "pure" declarative style.
-
@mpts @lobocode I can't fully agree. "Make" is declarative by nature, and a fully declarative Makefile contains nothing but variable expansions and rules with recipes. I *would* agree that #bmake makes it easier to write such a Makefile in many cases for its powerful expansion modifiers (some of which you can't even simulate with gmake's custom functions, like substitutions using regular expressions). But OTOH, it also makes some "procedural" style easier by e.g. providing a "for" loop that runs at parse time (not available in #gmake).
That said, "!=" is a poor replacement for $(wildcard ): "!=" also runs at parse time, $(wildcard ) OTOH is a function only executed when needed for expansion. #bmake offers the "${:!...!}" expansion that would be a better match here (still with the drawback of having to call some external tool of course).
Of course, any "if" (and similar) forces immediate expansion of its arguments in both make flavors, therefore breaking the "pure" declarative style.
-
@mpts @lobocode I can't fully agree. "Make" is declarative by nature, and a fully declarative Makefile contains nothing but variable expansions and rules with recipes. I *would* agree that #bmake makes it easier to write such a Makefile in many cases for its powerful expansion modifiers (some of which you can't even simulate with gmake's custom functions, like substitutions using regular expressions). But OTOH, it also makes some "procedural" style easier by e.g. providing a "for" loop that runs at parse time (not available in #gmake).
That said, "!=" is a poor replacement for $(wildcard ): "!=" also runs at parse time, $(wildcard ) OTOH is a function only executed when needed for expansion. #bmake offers the "${:!...!}" expansion that would be a better match here (still with the drawback of having to call some external tool of course).
Of course, any "if" (and similar) forces immediate expansion of its arguments in both make flavors, therefore breaking the "pure" declarative style.
-
@mpts @lobocode I can't fully agree. "Make" is declarative by nature, and a fully declarative Makefile contains nothing but variable expansions and rules with recipes. I *would* agree that #bmake makes it easier to write such a Makefile in many cases for its powerful expansion modifiers (some of which you can't even simulate with gmake's custom functions, like substitutions using regular expressions). But OTOH, it also makes some "procedural" style easier by e.g. providing a "for" loop that runs at parse time (not available in #gmake).
That said, "!=" is a poor replacement for $(wildcard ): "!=" also runs at parse time, $(wildcard ) OTOH is a function only executed when needed for expansion. #bmake offers the "${:!...!}" expansion that would be a better match here (still with the drawback of having to call some external tool of course).
Of course, any "if" (and similar) forces immediate expansion of its arguments in both make flavors, therefore breaking the "pure" declarative style.
-
@lobocode They're just very different.
#gmake excells in "meta-programming", providing functions (builtin and custom) and the "evil" $(eval ...) (and indeed, code using that is hard to keep at least remotely readable), basically containing a functional programming language. OTOH, it sucks in surprising ways, e.g. it has no idea of numbers/arithmetics. It also has things I'd personally call total "misfeatures", like these default variable values, default rules, even pattern rules can bite you badly ...
Among the strong points of #bmake are many very concise and flexible variable expansion modifiers (including arbitrary replacements, also using regular expressions, and even a "loop expansion").
#FreeBSD makes good use of the nice #bmake features in its build systems (at least base and ports).
-
@lobocode They're just very different.
#gmake excells in "meta-programming", providing functions (builtin and custom) and the "evil" $(eval ...) (and indeed, code using that is hard to keep at least remotely readable), basically containing a functional programming language. OTOH, it sucks in surprising ways, e.g. it has no idea of numbers/arithmetics. It also has things I'd personally call total "misfeatures", like these default variable values, default rules, even pattern rules can bite you badly ...
Among the strong points of #bmake are many very concise and flexible variable expansion modifiers (including arbitrary replacements, also using regular expressions, and even a "loop expansion").
#FreeBSD makes good use of the nice #bmake features in its build systems (at least base and ports).
-
@lobocode They're just very different.
#gmake excells in "meta-programming", providing functions (builtin and custom) and the "evil" $(eval ...) (and indeed, code using that is hard to keep at least remotely readable), basically containing a functional programming language. OTOH, it sucks in surprising ways, e.g. it has no idea of numbers/arithmetics. It also has things I'd personally call total "misfeatures", like these default variable values, default rules, even pattern rules can bite you badly ...
Among the strong points of #bmake are many very concise and flexible variable expansion modifiers (including arbitrary replacements, also using regular expressions, and even a "loop expansion").
#FreeBSD makes good use of the nice #bmake features in its build systems (at least base and ports).
-
@lobocode They're just very different.
#gmake excells in "meta-programming", providing functions (builtin and custom) and the "evil" $(eval ...) (and indeed, code using that is hard to keep at least remotely readable), basically containing a functional programming language. OTOH, it sucks in surprising ways, e.g. it has no idea of numbers/arithmetics. It also has things I'd personally call total "misfeatures", like these default variable values, default rules, even pattern rules can bite you badly ...
Among the strong points of #bmake are many very concise and flexible variable expansion modifiers (including arbitrary replacements, also using regular expressions, and even a "loop expansion").
#FreeBSD makes good use of the nice #bmake features in its build systems (at least base and ports).
-
@lobocode They're just very different.
#gmake excells in "meta-programming", providing functions (builtin and custom) and the "evil" $(eval ...) (and indeed, code using that is hard to keep at least remotely readable), basically containing a functional programming language. OTOH, it sucks in surprising ways, e.g. it has no idea of numbers/arithmetics. It also has things I'd personally call total "misfeatures", like these default variable values, default rules, even pattern rules can bite you badly ...
Among the strong points of #bmake are many very concise and flexible variable expansion modifiers (including arbitrary replacements, also using regular expressions, and even a "loop expansion").
#FreeBSD makes good use of the nice #bmake features in its build systems (at least base and ports).
-
@lobocode bmake makes you think about your makefile in a more declarative way. As a result, bmake supports querying Makefiles for the value of a variable, e.g., `bmake -V CC` would give you the value of CC.
Usually, it is possible to express the GNU Make functions with the "!=" assignment in bmake. E.g., when I need an equivalent of GNU Make's `$(wildcard ...)` I tend to use `FOO!= ls *` instead.
-
@lobocode bmake makes you think about your makefile in a more declarative way. As a result, bmake supports querying Makefiles for the value of a variable, e.g., `bmake -V CC` would give you the value of CC.
Usually, it is possible to express the GNU Make functions with the "!=" assignment in bmake. E.g., when I need an equivalent of GNU Make's `$(wildcard ...)` I tend to use `FOO!= ls *` instead.
-
@lobocode bmake makes you think about your makefile in a more declarative way. As a result, bmake supports querying Makefiles for the value of a variable, e.g., `bmake -V CC` would give you the value of CC.
Usually, it is possible to express the GNU Make functions with the "!=" assignment in bmake. E.g., when I need an equivalent of GNU Make's `$(wildcard ...)` I tend to use `FOO!= ls *` instead.
-
@lobocode bmake makes you think about your makefile in a more declarative way. As a result, bmake supports querying Makefiles for the value of a variable, e.g., `bmake -V CC` would give you the value of CC.
Usually, it is possible to express the GNU Make functions with the "!=" assignment in bmake. E.g., when I need an equivalent of GNU Make's `$(wildcard ...)` I tend to use `FOO!= ls *` instead.
-
@lobocode bmake makes you think about your makefile in a more declarative way. As a result, bmake supports querying Makefiles for the value of a variable, e.g., `bmake -V CC` would give you the value of CC.
Usually, it is possible to express the GNU Make functions with the "!=" assignment in bmake. E.g., when I need an equivalent of GNU Make's `$(wildcard ...)` I tend to use `FOO!= ls *` instead.
-
#gmake (#GNU) or #bmake (#BSD, or other pmake descendant)?
Well, both excel and both suck, just in different areas. 🙈
When I started to build my own #make framework for my own projects, I opted for #gmake, just because it's more widespread and easy to get/install on most platforms.
gmake is strong with functions (even user-defined ones) and together with $(eval ...) can do some impressive meta-programming, even generating its own rules at runtime, although the code will be a bit hard to follow. One of its weaknesses that bother me most is, it doesn't know anything about numbers 😶 A simple thing like "is a greater than b" is close to impossible to answer without calling out to the shell ...
bmake seems quite compact and simple, typical BSD style, still with some strong features, e.g. very flexible variable expansions. It can do loops in a simple straight-forward way. bmake code tends to be more readable for more complex stuff, but also often a lot more verbose.
-
#gmake (#GNU) or #bmake (#BSD, or other pmake descendant)?
Well, both excel and both suck, just in different areas. 🙈
When I started to build my own #make framework for my own projects, I opted for #gmake, just because it's more widespread and easy to get/install on most platforms.
gmake is strong with functions (even user-defined ones) and together with $(eval ...) can do some impressive meta-programming, even generating its own rules at runtime, although the code will be a bit hard to follow. One of its weaknesses that bother me most is, it doesn't know anything about numbers 😶 A simple thing like "is a greater than b" is close to impossible to answer without calling out to the shell ...
bmake seems quite compact and simple, typical BSD style, still with some strong features, e.g. very flexible variable expansions. It can do loops in a simple straight-forward way. bmake code tends to be more readable for more complex stuff, but also often a lot more verbose.
-
#gmake (#GNU) or #bmake (#BSD, or other pmake descendant)?
Well, both excel and both suck, just in different areas. 🙈
When I started to build my own #make framework for my own projects, I opted for #gmake, just because it's more widespread and easy to get/install on most platforms.
gmake is strong with functions (even user-defined ones) and together with $(eval ...) can do some impressive meta-programming, even generating its own rules at runtime, although the code will be a bit hard to follow. One of its weaknesses that bother me most is, it doesn't know anything about numbers 😶 A simple thing like "is a greater than b" is close to impossible to answer without calling out to the shell ...
bmake seems quite compact and simple, typical BSD style, still with some strong features, e.g. very flexible variable expansions. It can do loops in a simple straight-forward way. bmake code tends to be more readable for more complex stuff, but also often a lot more verbose.
-
#gmake (#GNU) or #bmake (#BSD, or other pmake descendant)?
Well, both excel and both suck, just in different areas. 🙈
When I started to build my own #make framework for my own projects, I opted for #gmake, just because it's more widespread and easy to get/install on most platforms.
gmake is strong with functions (even user-defined ones) and together with $(eval ...) can do some impressive meta-programming, even generating its own rules at runtime, although the code will be a bit hard to follow. One of its weaknesses that bother me most is, it doesn't know anything about numbers 😶 A simple thing like "is a greater than b" is close to impossible to answer without calling out to the shell ...
bmake seems quite compact and simple, typical BSD style, still with some strong features, e.g. very flexible variable expansions. It can do loops in a simple straight-forward way. bmake code tends to be more readable for more complex stuff, but also often a lot more verbose.
-
#gmake (#GNU) or #bmake (#BSD, or other pmake descendant)?
Well, both excel and both suck, just in different areas. 🙈
When I started to build my own #make framework for my own projects, I opted for #gmake, just because it's more widespread and easy to get/install on most platforms.
gmake is strong with functions (even user-defined ones) and together with $(eval ...) can do some impressive meta-programming, even generating its own rules at runtime, although the code will be a bit hard to follow. One of its weaknesses that bother me most is, it doesn't know anything about numbers 😶 A simple thing like "is a greater than b" is close to impossible to answer without calling out to the shell ...
bmake seems quite compact and simple, typical BSD style, still with some strong features, e.g. very flexible variable expansions. It can do loops in a simple straight-forward way. bmake code tends to be more readable for more complex stuff, but also often a lot more verbose.
-
Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳
Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!
They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).
Ok, no #scons yet, didn't need it so far 🙈
-
Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳
Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!
They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).
Ok, no #scons yet, didn't need it so far 🙈
-
Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳
Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!
They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).
Ok, no #scons yet, didn't need it so far 🙈
-
Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳
Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!
They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).
Ok, no #scons yet, didn't need it so far 🙈
-
Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳
Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!
They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).
Ok, no #scons yet, didn't need it so far 🙈