On Fri, Oct 27, 2017 at 10:43 PM, James Turner <ja...@calminferno.net> wrote: > On Fri, Oct 27, 2017 at 10:34:36PM +0200, Peter Ljung wrote: >> On Thu, Oct 26, 2017 at 3:18 PM, James Turner <ja...@calminferno.net> wrote: >> > On Wed, Oct 25, 2017 at 10:58:51PM +0200, Peter Ljung wrote: >> >> This is my first attempt to make a port for the howl editor >> >> (https://howl.io/). >> >> >> >> I think howl is a *really* good alternative editor which compares well >> >> with e.g. >> >> Sublime Text for my uses. >> >> >> >> Also it doesn't come with a huge baggage like the Electron based editors >> >> Atom and VS Code. >> >> >> >> * The upstream code builds cleanly on OpenBSD since 0.4 release >> >> * A stability issue (I found) on OpenBSD was fixed in last point release >> >> 0.5.2 >> >> >> >> I have tried my best to create a suitable port. >> >> >> >> The current port is available at: >> >> >> >> https://github.com/peterljung/howleditor >> >> >> >> Some things I have came across ... >> >> >> >> * I have installed and tested the port on 6.1 and 6.2 release (amd64) >> >> * It is called howleditor to avoid conflict with avahi >> >> * Avahi has a "@conflict howl-*" in PLIST >> >> * I made a small patch in the Makefile to force setting PREFIX variable >> >> which otherwise is set by ports infrastructure >> >> >> >> Any tips for improvements? >> >> >> > >> > Hi Peter, >> > >> > Port looks pretty good. Biggest thing you're going to want to fix is how >> > Howl downloads external dependencies and builds them locally. You will >> > want to use our ports versions. Ie. LuaJIT, LPEG and maybe others. >> > >> > -- >> > James Turner >> >> Thanks for feedback! >> >> I actually asked upstream about using ports versions: >> >> As @kirbyfan64 said, we embed LuaJIT ourselves and link in statically. It >> would >> be theoretically possible to use 2.0.5, but we switched to 2.1-beta two years >> ago so I can't say for sure. Also, any LuaJIT would need to be compiled with >> the >> correct compile options also (lua 5.2 compat enabled). We also patch >> LUA_IDSIZE >> to be slightly larger. >> >> In short I see the desire to use a system Lua version, but as we don't link >> it >> dynamically there's nothing to gain with regards to executable size, and the >> needed changes above makes it not worth the while IMO. Release tarballs >> already >> contain a bundled copy of LuaJIT. >> >> ... >> >> So there are some reasons not to use port versions, but someone with more >> lua/porting experience might be able to determine what to do? >> > > Makes sense, I guess I was more concerned with the port downloading > dependencies, but if they are bundled with the tarball that takes care > of that concern. > > What are other peoples thoughts? > > -- > James Turner
I have made a few changes to the port from some suggestions by Edd. * I set PREFIX in MAKE_FLAGS as an alternative to patching the Makefile * Added c++abi to WANTLIB * Patched lpeg makefile to use clang (used gcc before) https://github.com/peterljung/howleditor/commits/master I also found an issue with the upstream release that need to be fixed. https://github.com/howl-editor/howl/issues/390
