On Wed, 3 Mar 2021 19:23:46 +0100 Marc Espie <[email protected]>: > On Wed, Mar 03, 2021 at 05:31:53PM +0100, Omar Polo wrote: > > > > Thanks Marc and Stuart for the replies! > > > > Marc Espie writes: > > > > > [...] > > > If you don't have anything to package, you can always use the lesser known > > > features of BUILD_DEPENDS > > > > > > See bsd.port.mk(5).... you will probably find > > > BUILD_DEPENDS = some/path:patch > > > > > > to be more or less what you would need. > > > > It took me a while to understand, but now I get it. I didn't know it > > was possible to specify the target in BUILD_DEPENDS. But the problem is > > that I would have to create a port for every dependency. Generally > > speaking this seems the best approach, but in this case, since this > > would be the second common-lisp port, I don't think it would be optimal. > > > Well... there are lots of ways to deal with ports with several dependencies. > I don't know how it's architected, really. > > Maybe having actual dependent ports which package would be even better ? > I don't know whether it makes sense to compile dependencies and bundle them > then do some kind of linking later... which is definitely what we do for > C, C++,perl... > > as far as having several ports go, it's not as bad as it may seem. > Another reminder: the ports tree on OpenBSD is not a flat two level structure > you could very easily stash everything under the same prefix in the ports tree > > > > Stuart Henderson <[email protected]> writes: > > > > On 2021/03/03 16:24, Omar Polo wrote: > > > [...] > > > Indeed MASTER_SITES can only go from <nothing> to 9, but as long as > > > there's > > > a common base URL you can use the "DISTFILES=local{remote}suffix" syntax. > > > Here's an example for converting stumpwm to use this. Some ports do > > > similar > > > for multiple github dependencies. > > > I have overlooked the DISTFILES variable! It looks great, I'll try this > > way. > > > If everything comes from one or two MASTER_SITES you will be fine like that > as well. > > > Sooner or later, assuming there is a sane ecosystem, you may need to package > things. >
I think an issue may arise. When you run load common lisp scripts, the interpreter will cache "compiled" file like python does with .pyc file, except we have a few common lisp interpreter in the ports tree and not only one. I have no idea how this should be handled or if it's really not an issue but this seems reasonsable to keep this in mind. About dependencies, one "simple" way would be to make a bundle/vendor directory using quicklisp and then use the new tarball including it for the port, but it's not really maintainable. This could be used as a workaround instead of porting many things. You could also look at x11/stumpwm downloading a few libraries for compilation purpose, they get included in the SBCL image runtime anyway.
