On Fri, Oct 27, 2017 at 10:34:36PM +0200, Peter Ljung wrote:
> On Thu, Oct 26, 2017 at 3:18 PM, James Turner <[email protected]> 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

Reply via email to