<ppetrov^>
if you run it with no arguments, it behaves as before; however running "prtcreate cmake" will generate a port with cmake build features
<ppetrov^>
I want to state clearly that I am not at all that familiar with the different build systems, I uses the SlackBuilds templates to do this. For example, I am a bit unclear what's the difference between cmake and ninja
<ppetrov^>
if prtcreate has such functionality, then we can think about how exactly the templates should look, so we may achieve some better standartization across ports maintained by different users
<ppetrov^>
so, the modified prtcreate accepts options: autotools, cmake, meson, ninja (not sure about that one...), perl, python and r
<farkuhar>
ppetrov^: thanks for the suggestion. I imagine that in the absence of such a feature, most maintainers would just proceed in the usual manner: copy an existing port that uses the same build system, and then edit the Pkgfile. But if the functionality was part of prtcreate, then they'd be less likely to propagate irrelevant build flags into the new port.
<ppetrov^>
well, it will be useful _for me_, at least
<farkuhar>
Speaking of build flags, remiliascarlet mentioned smaller binaries as the "only true advantage of dynamic/shared" linking. Supposedly CFLAGS="-Os" tries to minimize the size of the binaries, but probably not as effectively as the switch from static to dynamic linking.
<ppetrov^>
I am not participating in that debate. I have almost zero experience with static binaries, and even my limited work with them wa sa pain in the ass
<ppetrov^>
actually, speaking of build flags, which build systems require them to be specified in the port?
<ppetrov^>
can't /etc/pkgmk.conf be made to export flags for other than autotools?
<remiliascarlet>
It's a pain in the ass because of the poor decisions made in the past. I just successfully managed to statically link an example C code that uses libcurl, for that I had to include every library curl uses, and every library its dependencies use until you've got them all covered.
<remiliascarlet>
It's an absolute pain in the ass.
<remiliascarlet>
Which is why I appreciate the efforts made by the Go, Zig, and musl teams for making static linking a lot easier.
<farkuhar>
So that's at least two more languages (Go and Zig) that deserve a Pkgfile template, if we wanted to implement ppetrov^s suggestion. Rather than hard-code them into prtcreate directly, why not populate a directory /etc/prtcreate with the templates for each build system (the same way that /etc/ports/drivers has separate scripts for each method of syncing a repo)?
<farkuhar>
Users who code in exotic languages can then put their own templates in /etc/prtcreate, rather than editing the script in-place or putting a customized copy earlier in $PATH.
<ppetrov^>
farkuhar, yep, that's a good idea. I had them saparately at firest, e.g. cmake.Pkgfile, meson.Pkgfile, etc... but thought it would be faster to just dump them in the script itself
<ppetrov^>
but sure, making it look in the folder is more elegant. So if I make my own template for sth else, I can call it as well
<SiFuh>
Nice
<ppetrov^>
Go and Zig I have no idea how to build... there's also ruby, I guess
<remiliascarlet>
Go: `go build`. And Zig: `zig build`.
<ppetrov^>
heh
<ppetrov^>
well, glad you like the idea SiFuh
<remiliascarlet>
In most cases, the only dependencies for Go or Zig is going to be the compiler itself.
<ppetrov^>
i guess if we decide to do this, first thing would be to have a standardized set of ports templates. i guess the core devs can help here, as well
<ppetrov^>
ye, i have my moments. So, we can then run these at the script verification site you once sent, so when they are reported to have issues you can say "I told you so"
<SiFuh>
I've been doing it the same as you with the cmake.Pkgfile thing
<ppetrov^>
:P
<farkuhar>
ppetrov^: as far as standardizing cosmetic issues like spaces versus tabs, most build systems are very forgiving (inasmuch as they're driven by dash or bash). But when writing a Makefile that is interpreted directly by gmake, you can't treat spaces as interchangeable with tabs.
<ppetrov^>
well, i see some ports in core or opt use tabs, others use 2 spaces. I always used tabs, but kinda like the two spaces more: the port looks neater. But that's just a cosmetic thing
<farkuhar>
It's usually not a problem because the upstream devs are responsible for the Makefile. I can't think of any port that uses a here-doc inside build() to construct a Makefile directly.
<ppetrov^>
so, the different port templates can just contain the respective build() function. The port headers are the same anyway
<SiFuh>
I remember they went from tabs to spaces and from 4 spaces to two spaces. But it has changed to masically this "Indent your code properly and consistently. Use blank lines to separate paragraphs or logic blocks."
<farkuhar>
SiFuh: many of our official ports still rely on automatic word-splitting at whitespace, rather than the arrays that are recommended in the wooledge BashGuide. You might encounter a lot of resistance writing a template that used "${BUILD_FLAGS[@]}" instead of the (currently more ubiquitous) $BUILD_FLAGS.
<farkuhar>
There was another camille who got involved in CRUX packaging some years ago. IRC nick was onodera, maybe? Anyway, that camille started reimplementing prt-get and ports in Go: https://github.com/CamilleScholtz/prt
<SiFuh>
I remember onodera
<cruxbot>
[core/3.7]: python3-setuptools: updated to version 69.5.1