[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Package building

From: Andreas Fink
Subject: Re: Package building
Date: Wed, 20 Nov 2019 10:56:57 +0100

> On 20 Nov 2019, at 10:55, Richard Frith-Macdonald <address@hidden> wrote:
>> On 20 Nov 2019, at 08:37, Andreas Fink <address@hidden> wrote:
>>> On 20 Nov 2019, at 08:59, Johannes Brakensiek <address@hidden> wrote:
>>> Hey Ivan,
>>> thank you for your work and your explanations!
>>> On 20 Nov 2019, at 3:10, Ivan Vučica wrote:
>>>> Now... developers may need updated versions when developing their apps. I 
>>>> remember Debian not shipping with NSViewController or NSWindowController 
>>>> when I first came around -- but on the other hand, when I would cut a 
>>>> release, an updated .deb would follow. (Not to mention our source code 
>>>> became much more discoverable, so seeing if a class is missing is much 
>>>> easier too.)
>>>> So when a developer needs a newer version so they can prepare a source 
>>>> tarball for Debian to integrate... they can talk to us. We cut our 
>>>> release, a Debian maintainer (e.g. Yavor) picks it up, the app gets picked 
>>>> up too, everyone happy.
>>>> Yes, I would say developers are very welcome to advocate with maintainers 
>>>> for a release if not cutting one blocks their app's release. :-)
>>>> And at this time, I am still here to help component maintainers with a 
>>>> release. I may not do it on a tight schedule, but eventually I’ll find an 
>>>> evening or two to tackle this kind of request.
>>>> Do you have a specific anecdote about something you wanted up to date, as 
>>>> a binary, which wasn’t in your favorite distro?
>>> The problem simply is that f.e. Debian ships libs that are build with GCC 
>>> and thus are missing any of the new language features. I understand you are 
>>> doing this for compatibility with other processor platforms. But this leads 
>>> to the problem that any app developer who wants to build a new app based 
>>> upon the clang ABI has to build and ship everything on his own. I really 
>>> think this is a show blocker for attracting new developers (or even users). 
>>> Or did I miss anything here?
>>> Johannes
>> I can completely agree on this statement. Due to modern code using ARC 
>> everywhere, the gnustep coming with Debian (which is  my main deployment 
>> platform) is usually a problem. I always have to make sure its not installed 
>> and install my own packaged version. On the other hand I have not seen 
>> anyone using ObjectiveC without ARC these days.. Its nice to have for 
>> nostalgia but ARC has solved a million problems for me in my code over the 
>> last decades. So today, I would not even think to do anything with gnustep 
>> without clang.
>> Having a gnustep which works with arc and without arc would be ok. but 
>> shipping packaged versions with libraries which can not work with ARC is a 
>> show stopper.
>> And when GNUStep wants to continue following the development of OSX's 
>> platform, ARC is there since more than a decade and everyone depends on it. 
>> So if anyone wants to port OS X code to Linux and considers GNUStep as a 
>> logica platform, then ARC support is a must.
> I have never used a mixed configuration, but from what David's said in the 
> past (I expect he will correct me if I'm wrong),  for the libraries ARC 
> should work whether or not GNUstep is built with clang.
> The libraries do not need to use ARC internally in order to be used by 
> software that is built for ARC, as long as they are built for the same 
> runtime.

there's the catch..  the current distros all come with the old runtime and 
thats where everything falls apart miserably.

> But if a distribution provides gnustep-make configured to use gcc, you would 
> need to install/configure your own version to use clang.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]