> On Sep 28, 2024, at 11:14 PM, Ken Cunningham 
> <[email protected]> wrote:
> 
> 
> 
>> On Sep 28, 2024, at 8:47 PM, Gagan Sidhu via macports-dev 
>> <[email protected]> wrote:
>> 
> 
>> in my opinion, and while it’s clear the lack of weak references and thread 
>> local storage in 10.6 is a disadvantage,
> 
> weak references and thread_local (emulated_tls, just like gcc does) work 100% 
> just fine on 10.5 and 10.6, and have done so for years now
i understand the macports compilers offer these featuers, but i was just 
referring to the operating system features.

> 
> 
> 
> 
>> we’re sitting on a gold mine and it’s like such a shock we’re letting those 
>> BREWsers (brew losers) just take our spot.
>> 
>> something must be done about this. they are losers. yes i did just “ad 
>> hominem” them (i bet they like richard dawkins too, like real losers do)
> 
> 
> 
> 
> I don't know what you are referring to.
> 
> You can build almost any software you want, right now, on 10.5 and 10.6 using 
> the current libcxx port on those systems, and the system lib++ on 10.7 up. 

i think in this past week i’ve used ports more than i ever have in the past 
twenty years of installing it, and while your general statement is correct, i 
must provide some corrections to it below.
> 
> 
> And for systems where the installed libc++ is too old (usually requiring 
> filesystem, which came in with 10.15) we boot them up to use macports-libcxx 
> quite successfully.
> 
> 
> I appreciate your enthusiasm. I think you need to spend quite a bit more time 
> understanding how things work in MacPorts now, as what you are proposing 
> actually offers nothing we don't already have.

with your macports-libcxx, i can’t disagree that macports has everything. but 
the question is: does it all work out of the box? the answer is ’no’.

examples:

1. the latest gdb is ‘broken’ because it relies on sp_mut from a libc++ newer 
than what is on 10.7, and the build will fail ‘out of the box’.
        -gdb universal is ‘broken’ because there are more comments needed to 
the newer makefiles to ensure the libtool archive files do not clash when 
merging the destroots of i386 and x86_64
2. as explained earlier this week, both nodejs14 and nodejs18 fail to build on 
10.7 because no one has tried to build them on 10.7 and look at the issues.
        -the current portfiles simply stop anyone from trying to even install 
it on macs lower than 10.9
3. lldb-mp-xx will fail pretty badly on (5.0 and up) 10.7, and i don’t think 
this is just a matter of a libcxx. it took a few involved edits. not saying 
they were super-hard, but they weren’t easy.

in short, you are correct that users are able to build “any software you want”, 
but only with some involved  _EDITS_ of the _CURRENT_ portfiles of the 
aforementioned ports.
        -this is challenging for people who may have experience in development, 
but none that are relevant to macports (though i’ve leeched for 20 years 
almost) for two reasons:
                1. there is new syntax/nomenclature/familiarity required in 
modifying the portfiles themselves
                2. there are changes required to the actual build (i.e. 
cflags/ldflags etc) that also need to be discovered by ‘playing’ with the build 
directory in /opt/local/var/macports/build/*software*
        -the knowledge in step 2 then needs to be summarised into step 1, which 
shows there are two layers of experience to contribute effectively to the 
macports system.

it is a great front-end and i appreciate it very much, but i really ‘had to 
care’ before i learned about this two-stage process mentioned above.

of course the next question would be: are we expecting the macports user to 
know how to do all of this? 
        -i guess that goes to the ethos of the package manager maintainers. 

personally i think i’ve shown i haven’t suffered if that is your expectation. 
        -BUT with some maintenance of existing portfiles for popular software, 
i think macports popularity could increase significantly and that is the 
perspective from which i penned this topic.

maybe no one cares about that though lol.

> 
> 
> 
> Ken
> 
> 



Thanks,
Gagan

Reply via email to