Re: Package building

[Andreas Fink]

> On 20 Nov 2019, at 10:55, Richard Frith-Macdonald 
> <richard@frithmacdonald.me.uk> wrote:
> 
> 
> 
>> On 20 Nov 2019, at 08:37, Andreas Fink <afink@list.fink.org> wrote:
>> 
>> 
>> 
>>> On 20 Nov 2019, at 08:59, Johannes Brakensiek <johannes@brakensiek.info> 
>>> 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.
>