Re: Package building

[Richard Frith-Macdonald]

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