<sewn>
do muon/meson build files use the build directory as 'output' or 'build'? which is preferred
<illiliti>
the one you like more
<sewn>
the one the maintainer of the package likes more*
yamchah2 has quit [Remote host closed the connection]
yamchah2 has joined #kisslinux
<xdream8[m]>
When that muon pr will be merged?
<sewn>
its literally freah
<sewn>
fresh
<sewn>
atleast give it like one kiss maintainer meeting
sad_plan has joined #kisslinux
<sad_plan>
hi
<sad_plan>
sewn: on sabotage, mesa is split into separate packages. one of which is for radeon/amd gpu. which obviously requires llvm which you mentioned. you could look at that. as iirc, they have a switch for it
<sewn>
smart actually
<sad_plan>
yep.
<sad_plan>
not sure how the switch works, but it could be worth looking into in any case
<illiliti>
split could be done with provides system
<sad_plan>
sure
<sewn>
provides system coming near you in never
<sewn>
a provide system can be somewhat implemented by having simply different repositories
<sad_plan>
lol. its been mentioned a couple times here, but its seems difficult to implement. i dunno
<sewn>
it would require fake naming packages no?
<sewn>
one can implement a provides system by just using different repositories
<sewn>
another way I can put it is to add it to the 'depends' array as a 'replace' key and to have the end package name to be the replaced package
<sewn>
how about that?
<sewn>
or to have it be some file that's touched in the build file idk
<sad_plan>
I was thinking more in line with using the manifest file, and just.. grepping it or w/e. not sure how practical that would be though
<sewn>
I don't get what you mean
<sad_plan>
say if a package specifically requires assert.h file, kiss would look for that file, and see what package provides said file, and then make sure said package is installed, if not, the build/install it
personifieddevil has quit [Read error: Connection reset by peer]
<sewn>
that is significantly slow as let's say a package needs a giant library and its thousands of headers, it wouldn't be safe to check for one file as maybe one is missing, one would need to check for each file to see if they belong to a package, one by one.
<sewn>
I think that would be very slow
<sewn>
personally I don't see another way to implement it other than fake name packaging
<sad_plan>
it would absolutely be slower than a snail
<sad_plan>
which is why I said it wouldnt be practical
<sad_plan>
in a situation like oasis, this makes somewhat sense, as its repo is very small, and only consists of smaller projects, so figuring out what headers and so on is needed is somwhat trivial
<sewn>
I'm pretty sure even oasis doesn't need a provides system, as there isn't even any dependency management
<sad_plan>
it doesnt, but itll only build w/e is needed, more or less. it does have a *system* for dependencies, its just in the buildfiles instead
<sad_plan>
i.e. in a gen.lua file for i.e. velox, youd see that it includes files from different other packages. its specific to specific headers though, just.. headers from said package
<sad_plan>
like velox would have included header files from fontconfig, libinput, and so on
<sewn>
sad_plan: you forgot the fact that when defining the executable or library, the library itself is added as a source file, hence linking to it
<sewn>
I think this is very impressive
<sad_plan>
it was just a simple explenation, but yes, that would be correct.