On Sat, Nov 4, 2017 at 4:15 PM, Peter Ljung <ljung.pe...@gmail.com> wrote: > 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
I have made a release bump to latest howl point release which includes a fix for the scrollbar issue. https://github.com/peterljung/howleditor It seems to work fine now, but more eyes and testing would obviously be great.
