I decided to include asdf, rawsock, i18n, regexp, syscalls and readline modules in clisp recipe as suggested by CLISP team. The rest of packages (which have additional dependencies) will go to clisp-modules recipe, which hopefully will come some time after that.
For now the recipe does not contain link to Haiku specific text editor and web browser, and only contains asdf and rawsock modules. The work is ongoing upstream for this.
I could build another 9 CLISP modules out of 26 (plus 2, which are already included in CLISP recipe). One more module seems buildable but needs work-around either in external _devel package or in recipe.
Unfortunately, CLISP seem to not play well with sockets. CLISP team says:
Sockets have been a known problem with BeOS. It is possible that for these
historical reason, they are still problematic with Haiku.
Because I am a sort of communication channel between CLISP and Haiku rather than a true developer, how well new implementation is discoverable via autotools? Is there something special that needs to be changed in .c code or in configure script etc?
There would be few adjustments to the code or none depending on the socket used, these commits have comments and codes, which serve as a reference to know which sockets are in Haiku and how to implement them:
Looking at the Clisp code, you would have to mess with .m4, .d and .c files related to sockets, they assume that Haiku uses libnetwork without sockets, there are some dated things related to Haiku alpha 2, there is Unix socket code related to ipv6 in Clisp, Haiku does not yet have an ipv6 implementation.
unix sockets are something different, and network sockets are not implemented in libbsd.
So, the only thing to know is you need to link to libnetwork. Other than that, it should be identical to other unix systems, and if you have any beos specific code, you should remove it.
Iâm talking about the Clisp source code, which I analyzed quickly, youâre mixing things up, my previous post and the last one are different things, previously I talked about the new implementations in Haiku, in the last post I talked about the Clisp code and I put a link to understand how Unix sockets work in Haiku.
CLISP team pointed to one problem in CLISP recipe: it REQUIRES some more libraries.
Additionally, I managed to build some modules which are bundled with CLISP. Each of them usually deals with one or more 3rd-party library. CLISP suggests to pack each such module individually in separate hpkg package. All them are about 1.5 MB in size, and could be packed together. However they depend on different runtime libraries. In usual use-case a user will need one or two modules with only 3rd-party libraries necessary for them. So, what packaging option would you suggest?
Pack modules individually (there are 9 modules outside of main CLISP package) and each REQUIRES its runtime dependency.
Pack modules together and REQUIRE all their dependencies (of which only one or two will be actually used).
Pack modules together and do not REQUIRE their dependencies in hope that user will anyway install these dependencies if user works with them.
Pack modules together with main CLISP and REQUIRE CLISP runtime dependencies with all modules dependencies.
Pack modules together with main CLISP and REQUIRE only CLISP runtime dependencies.
Something else.
Also, I see some recipes produce more than one package. It would make sense to produce all CLSP related packages from the same recipe. How is it possible?
It depends on the libraries, I believe separate packages are created for each library, if other software uses them, but they are libraries only used by Clisp, perhaps you can create unique packages.
I only checked with the default archive containing all those modules, do they require the same archive or could you skip building clisp and only build those modules missing atm?
The modules should be able to built having clisp in BUILD_REQUIRES. But it is also possible to build at the same time CLISP with certain modules in a package and rest of buildable modules in separate package(s) from the same working directory.
I guess itâs up to you how you would love it to be packaged, looking at Repology I donât see sub-packages listed there, also the extra size with all-in-one package wouldnât be that bad imho.
The extra-size is not a problem at all. The true problem is extra-dependencies. Say, I intend to use CLISP to interact with pcre. Evidently, pcre library is a must for this. Also install clisp_modules package, which REQUIRES pcre. But, because clisp_modules contains also other CLISP modules, which depend on other runtime libraries, I end up installing also berkeley-db, openldap, postgresql etc without actually needing all them.
OK, for now for testing purpose I created a pull request with all modules together.
One more possibility (if it is fair one) would be to not list dependencies, and just let users install them when really needed (aka âsuggestedâ dependency in Debianâs apt package manager). The necessary dependency anyway will be installed, the missing other dependencies do not create problems as long as CLISP modules for them are not used.
For some reason, CLISP recipe for main package and separate modules fails to be built by buildbot. The error is different each time, but it seems to be a not found dependency (runtime or build time) and is different from an attempt to another (lib:libffi, lib:libdb). Strange, all these dependencies are available and exactly the same dependencies were declared in previous recipe, which succeed.
On the other hand, I see a new (?) package is attempted to be build: clisp_source. How this one is built? Which haikuporter options or which other tools are used? Maybe in my local environment I do not reproduce the failure because I do not perform all the steps done by buildbot?
EDIT: I see clisp_source is available in Depot, so it is not a new package. Still, what steps do buildbots?
@korli pushed a fix, clisp and friends are build now on both buildmasters, wanted to give you some time to do it yourself here.
Anyway, up and ready to install from the depot now, thanks!
If you look at the recipe providing devel:libdb$scondaryArchSuffix, you will also see that there isnât a lib:libdb$secondaryArchSuffix (mentioned in the other PR comments).
