[SailfishDevel] Harbour compatibility - including multiple executables in a single RPM

David Llewellyn-Jones david at flypig.co.uk
Fri Jun 1 08:53:10 UTC 2018


On 01/06/18 09:07, rinigus wrote:
> Hi David,
> 
>     > the rules regarding single executable haven't changed, to my knowledge.
> 
>     I actually can't see anything in the rules that states you can't have
>     multiple executables, but it is a requirement to pass through the
>     rpmvalidator. If it's a requirement, I'm thinking it would be helpful to
>     make this explicit in the FAQ (which is the closest thing I'm aware of
>     to a stated set of rules).
> 
> 
> You are probably right, but I haven't checked the text of the rules
> recently. They may "hide" it behind that you are expected to have your
> exe be called harbour-something and only that way.

Right, that's the only part that I can find that implies
single-executable, but I wouldn't call it explicit or transparent.

I guess my point - which isn't directed at you of course! - is that it's
important for Jolla to be really clear in the FAQ, because this is the
part you read *before* you start designing the architecture, whereas the
rpmvalidator is only something you can apply after you're already too
far down the road to change it.

> 
>     > That particular problem was solved for my case by writing a wrapper and
>     > called either QML main or the main I wanted to use from Valhalla
>     > (https://github.com/rinigus/osmscout-server-route/blob/master/src/harbour-osmscout-server-module-route.cpp#L19
>     <https://github.com/rinigus/osmscout-server-route/blob/master/src/harbour-osmscout-server-module-route.cpp#L19>).
> 
>     Just so I'm clear, for your workaround you joined the two code bases at
>     compile time?
> 
> 
> Yes, exactly this way

Thanks; that makes sense. It's a good solution.

>     Unfortunately that won't work in my case, because I have my programme
>     (C++) calling a Perl programme, which then calls another (C-complied)
>     executable. It's possible using Perl would be reason enough to reject
>     from Harbour, but one step at a time! The issue of multiple executables
>     seems more fundamental to me.
> 
>     > This solution would work, but its a touch harder to maintain. In the
>     > end, its up to you whether you want to have the app in the harbour or
>     > not. After all, its your decision. However, I would suggest to consider
>     > distribution via OpenRepos and not waste too much time for working
>     > around Harbour rules. 
> 
>     Ultimately, I agree it's much simpler to release through OpenRepos (I'm
>     already doing this in fact), and I can appreciate the frustration for
>     you of having to pull your app later. At least you achieved it, even f
>     just temporarily. Getting something into Harbour is an important life
>     goal for me ;)
> 
> 
> I understand, its a sport in the beginning. There is a simpler solution
> - you can always release a fart app for getting into the store :)

Yes, unfortunately "not releasing a fart app" is also one of my life
goals :)

I make light of it, but it's actually more than a sport. I submitted my
first app back in 2014 and I'm still trying. Developers are held back by
Harbour's restrictive policies and lack of support for payment, while
user adoption is held back by lack of apps in the store (or so people
say). Anything that increases the quantity of quality docked apps in the
harbour has to be a good thing.

At the same time, the Harbour rules should represent a checklist of
good-practice for developers, so I like to follow the guidelines if I
can, even if my app will never be accepted. I assume there's a good
reason for all of the rules :/ I'm not sure what the reason for
restricting multiple binaries is, though.

Sorry if this sounds ranty; it's not directed at you if it does!

David
-- 
Website: http://www.flypig.co.uk


More information about the Devel mailing list