Re: port diagnose and xcode

[Ryan Schmidt]

On Mar 27, 2022, at 13:06, Richard L. Hamilton wrote:
> 
> (although I think Apple provides the servers)

Apple provided the servers from late 2006 [1] (when our first home OpenDarwin 
closed its doors) until late 2016 [2] (when Apple's macOS forge service shut 
down). Since then, we have used GitHub and provided our own servers.

[1] 
https://web.archive.org/web/20070315221536/http://darwinports.opendarwin.org/archives.php?id=36

[2] https://lists.macports.org/pipermail/macports-dev/2016-August/033405.html

Re: port diagnose and xcode

[Richard L. Hamilton]

MacPorts is by nature not just one thing. There's the "port" command, related 
commands, the  structure of Portfiles; there's the servers that deliver up both 
pre-built executables AND whether for lack of capacity to pre-build or because 
certain ports need to be locally built, may also deliver packaged source that 
builds locally. All of that and maybe more is MacPorts itself.

And then there's the individual ports. Those are maintained (or sometimes not) 
by different people, and very dependent on the "upstream" supplier of the 
project, who may not always accept patches specific to make it work on a Mac 
(let alone older macOS versions), so that port may have to have and apply its 
own patches, which adds delay between upstream update and port update.

Even IF there was one vision of what MacPorts should do, that's quite a lot and 
although it really tries, CANNOT guarantee consistent results on everything for 
everyone - nothing can, and esp. nothing with mostly unpaid volunteers can 
(although I think Apple provides the servers).

Taking all that into account (and I'm NOT part of the "team" just another user, 
so some of that may not be 100% accurate), you might consider clarifying just 
what you want.

Doubtless brew and fink also have some difficulties getting everything just 
right (modulo different opinions of what "just right" might be). So you might 
find that you'll NEVER be happy. If that turns out to be the case, it might be 
your expectations rather than anyone else's performance needs to be 
re-evaluated.

> On Mar 27, 2022, at 09:25, Michele Venturi  wrote:
> 
> That's what I said and anyway I repeat for the nth time
> to people that doesn't want to know it: it's YOUR stuff,
> YOU should know what it is, I'm not here to tell you what
> to do you with it, this just a friendly reminder to decide...
> 
> Il dom 27 mar 2022, 01:42 Ryan Schmidt  > ha scritto:
> On Mar 26, 2022, at 00:48, Michele Venturi wrote:
> 
> > As usual this project too is a mess because everyone has a different idea 
> > of what it is,has been and will be.
> 
> If you have constructive criticism for changes that should be made, feel free 
> to start discussions about them. Otherwise you may be happier using something 
> else.
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: port diagnose and xcode

[Michele Venturi]

That's what I said and anyway I repeat for the nth time
to people that doesn't want to know it: it's YOUR stuff,
YOU should know what it is, I'm not here to tell you what
to do you with it, this just a friendly reminder to decide...

Il dom 27 mar 2022, 01:42 Ryan Schmidt  ha scritto:

> On Mar 26, 2022, at 00:48, Michele Venturi wrote:
>
> > As usual this project too is a mess because everyone has a different
> idea of what it is,has been and will be.
>
> If you have constructive criticism for changes that should be made, feel
> free to start discussions about them. Otherwise you may be happier using
> something else.
>
>

Re: port diagnose and xcode

[Ryan Schmidt]

On Mar 26, 2022, at 00:48, Michele Venturi wrote:

> As usual this project too is a mess because everyone has a different idea of 
> what it is,has been and will be.

If you have constructive criticism for changes that should be made, feel free 
to start discussions about them. Otherwise you may be happier using something 
else.

Re: port diagnose and xcode

[Michele Venturi]

As usual this project too is a mess because everyone has a different idea
of what it is,has been and will be.

Il gio 24 mar 2022, 02:55 Ryan Schmidt  ha scritto:

> On Mar 23, 2022, at 08:48, Michele Venturi wrote:
>
> > If MacPorts is not a package manager we need one,
> > I'd say HomeBrew could be the right tool for the job.
>
> I'm not sure what these remarks are in regards to, but MacPorts was
> started in 2002 a ports collection [1] based conceptually on FreeBSD Ports,
> meaning that it builds things from source on the user's system using a
> recipe. In 2011 MacPorts 2.0.0 was released which included the capability
> to download precompiled archives from servers, thus saving the user the
> need to compile it themselves, while still retaining the ability for them
> to do so should they wish to or need to. Shortly thereafter we began
> producing such archives for Mac OS X 10.6 on our servers, and we added
> archives for subsequent OS versions as they were released over the years.
> In that capability, MacPorts is like a package manager [2]. In my view it
> is a combination of both.
>
> Homebrew is a MacPorts competitor which came onto the scene in 2009. We
> welcome this friendly competition. Homebrew developers sometimes take
> patches or ideas from MacPorts; we sometimes take patches from them (and
> from anywhere else we can find them of course).
>
>
> [1] https://en.wikipedia.org/wiki/Ports_collection
> [2] https://en.wikipedia.org/wiki/Package_manager
>
>

Re: port diagnose and xcode

[Ryan Schmidt]

On Mar 23, 2022, at 08:48, Michele Venturi wrote:

> If MacPorts is not a package manager we need one,
> I'd say HomeBrew could be the right tool for the job.

I'm not sure what these remarks are in regards to, but MacPorts was started in 
2002 a ports collection [1] based conceptually on FreeBSD Ports, meaning that 
it builds things from source on the user's system using a recipe. In 2011 
MacPorts 2.0.0 was released which included the capability to download 
precompiled archives from servers, thus saving the user the need to compile it 
themselves, while still retaining the ability for them to do so should they 
wish to or need to. Shortly thereafter we began producing such archives for Mac 
OS X 10.6 on our servers, and we added archives for subsequent OS versions as 
they were released over the years. In that capability, MacPorts is like a 
package manager [2]. In my view it is a combination of both.

Homebrew is a MacPorts competitor which came onto the scene in 2009. We welcome 
this friendly competition. Homebrew developers sometimes take patches or ideas 
from MacPorts; we sometimes take patches from them (and from anywhere else we 
can find them of course).


[1] https://en.wikipedia.org/wiki/Ports_collection
[2] https://en.wikipedia.org/wiki/Package_manager

Re: port diagnose and xcode

[chilli.names...@gmail.com]

MacPorts is, by a long margin, the best package manager for macOS and Mac OS X 
before it. 

Homebrew is more like a cult than a package manager, and it has always been 
redundant and inferior to MacPorts. It is inferior due to the way it botches 
permissions, and specifically the way it creates security issues by annexing 
and changing the permissions and ownership of /local/bin

Homebrew was never not broken. It was always a bloody mess.

> On Mar 23, 2022, at 09:49, Michele Venturi  wrote:
> 
> If MacPorts is not a package manager we need one,
> I'd say HomeBrew could be the right tool for the job.

Re: port diagnose and xcode

[Michele Venturi]

My problem is that "MacPorts is not (just) 'a simple package manager'. "

Il mer 23 mar 2022, 21:11 Dave Horsfall  ha scritto:

> On Wed, 23 Mar 2022, Michele Venturi wrote:
>
> > If MacPorts is not a package manager we need one,I'd say HomeBrew could
> > be the right tool for the job.
>
> I find that MacPorts is a most excellent package manager; what exactly is
> your problem?
>
> -- Dave
>

Re: port diagnose and xcode

[Dave Horsfall]

On Wed, 23 Mar 2022, Michele Venturi wrote:

> If MacPorts is not a package manager we need one,I'd say HomeBrew could 
> be the right tool for the job.

I find that MacPorts is a most excellent package manager; what exactly is 
your problem?

-- Dave

Re: port diagnose and xcode

[Michele Venturi]

If MacPorts is not a package manager we need one,
I'd say HomeBrew could be the right tool for the job.

Il lun 14 mar 2022, 18:02 Ryan Schmidt  ha scritto:

> On Mar 14, 2022, at 10:40, James Secan wrote:
>
> > It is a macOS alias.  I use soft links a lot, but only for items that
> I’m accessing when working in a Unix shell.
>
> MacPorts should be able to use your Xcode wherever it is, provided that
> `xcode-select -p` shows its path or the path of a symlink to it. The path
> to a macOS alias to it probably won't work.
>
>

Re: port diagnose and xcode

[Ryan Schmidt]

On Mar 14, 2022, at 10:40, James Secan wrote:

> It is a macOS alias.  I use soft links a lot, but only for items that I’m 
> accessing when working in a Unix shell.

MacPorts should be able to use your Xcode wherever it is, provided that 
`xcode-select -p` shows its path or the path of a symlink to it. The path to a 
macOS alias to it probably won't work.

Re: port diagnose and xcode

[James Secan]

It is a macOS alias.  I use soft links a lot, but only for items that I’m 
accessing when working in a Unix shell.

Jim
3222 NE 89th St
Seattle, WA 98115
(206) 430-0109

> On Mar 13, 2022, at 1:46 PM, xpl...@wak.co.nz wrote:
> 
> I forgot to ad, the reason, at a unix level, the Finder alias just just 
> another boring file, not the intended alias. This is similar to how Windows 
> shortcuts look on Macs, where they come through as a .lnk file that the Mac 
> doesn’t understand.
> 
> -- 
> Richard Smith
> xpl...@wak.co.nz
> 
> 
> 
> 
>> On 14/03/2022, at 09:43, xpl...@wak.co.nz wrote:
>> 
>> Is it a Mac Alias, or a unix ln ? (i.e. the former is created with a 
>> drag-n-drop of the App holding down the Command & Option keys, while the 
>> former is created with the command ln -s /path/to/app lnfile, and that is a 
>> lowercase L, not an uppercase i). MacPorts will work better with the latter 
>> ln alias, not the former finder created alias.
>> 
>> -- 
>> Richard Smith
>> xpl...@wak.co.nz
>> 
>> 
>> 
>> 
>>> On 14/03/2022, at 06:41, James Secan  wrote:
>>> 
>>> I do have the full Xcode package installed (8.2.1) on the El Capitan 
>>> system, although I have it as an alias in the Applications directory (on a 
>>> smallish SSD) linking to the actual Xcode files on an internal HD because 
>>> it requires a lot of disk real estate and I never use Xcode.  Would that 
>>> confuse port diagnose?  (I just checked, and if I click on the Xcode alias 
>>> it works just as one would expect, so the alias linkage is OK.)
>>> 
>>> Jim
>>> 3222 NE 89th St
>>> Seattle, WA 98115
>>> (206) 430-0109
>>> 
 On Mar 12, 2022, at 6:42 PM, Ryan Schmidt  wrote:
 
 On Mar 10, 2022, at 18:40, James Secan wrote:
 
> In working my way through my recent “phantom ports” issue I ran the 
> command “port diagnose” and was more than a bit surprised by the output 
> line:
> 
> Error: currently installed version of Xcode, none, is not supported by 
> MacPorts.
> 
> followed by a list of the version supported under my version of macOS (El 
> Capitan, in this case).  Where is port getting this information?  I have 
> Xcode 8.2.0 installed, and none of my attempts to install ports have run 
> into any trouble related to Xcode not being installed.  I ran "pkgutil -v 
> --pkg-info=com.apple.pkg.CLTools_Executables” which shows that I have 
> 8.2.0 installed, and the appropriate MacOSX.sdk files are in 
> /Library/Developer/CommandLineTools/SDKs.  I also tried this on my test 
> Catalina system, with the same result.
> 
> Is something wrong with my ports setup?
 
 
 Both com.apple.pkg.CLTools_Executables and 
 /Library/Developer/CommandLineTools/SDKs are related to the Xcode command 
 line tools, which are separate from Xcode. So I guess you have the Xcode 
 command line tools installed but do not have Xcode installed. For many 
 ports, this is fine. For those where it is not, they should tell you to 
 install Xcode.
 
>>> 
>> 
> 

Re: port diagnose and xcode

[xplora]

I forgot to ad, the reason, at a unix level, the Finder alias just just another 
boring file, not the intended alias. This is similar to how Windows shortcuts 
look on Macs, where they come through as a .lnk file that the Mac doesn’t 
understand.

-- 
Richard Smith
xpl...@wak.co.nz




> On 14/03/2022, at 09:43, xpl...@wak.co.nz wrote:
> 
> Is it a Mac Alias, or a unix ln ? (i.e. the former is created with a 
> drag-n-drop of the App holding down the Command & Option keys, while the 
> former is created with the command ln -s /path/to/app lnfile, and that is a 
> lowercase L, not an uppercase i). MacPorts will work better with the latter 
> ln alias, not the former finder created alias.
> 
> -- 
> Richard Smith
> xpl...@wak.co.nz 
> 
> 
> 
> 
>> On 14/03/2022, at 06:41, James Secan > > wrote:
>> 
>> I do have the full Xcode package installed (8.2.1) on the El Capitan system, 
>> although I have it as an alias in the Applications directory (on a smallish 
>> SSD) linking to the actual Xcode files on an internal HD because it requires 
>> a lot of disk real estate and I never use Xcode.  Would that confuse port 
>> diagnose?  (I just checked, and if I click on the Xcode alias it works just 
>> as one would expect, so the alias linkage is OK.)
>> 
>> Jim
>> 3222 NE 89th St
>> Seattle, WA 98115
>> (206) 430-0109
>> 
>>> On Mar 12, 2022, at 6:42 PM, Ryan Schmidt >> > wrote:
>>> 
>>> On Mar 10, 2022, at 18:40, James Secan wrote:
>>> 
 In working my way through my recent “phantom ports” issue I ran the 
 command “port diagnose” and was more than a bit surprised by the output 
 line:
 
 Error: currently installed version of Xcode, none, is not supported by 
 MacPorts.
 
 followed by a list of the version supported under my version of macOS (El 
 Capitan, in this case).  Where is port getting this information?  I have 
 Xcode 8.2.0 installed, and none of my attempts to install ports have run 
 into any trouble related to Xcode not being installed.  I ran "pkgutil -v 
 --pkg-info=com.apple.pkg.CLTools_Executables” which shows that I have 
 8.2.0 installed, and the appropriate MacOSX.sdk files are in 
 /Library/Developer/CommandLineTools/SDKs.  I also tried this on my test 
 Catalina system, with the same result.
 
 Is something wrong with my ports setup?
>>> 
>>> 
>>> Both com.apple.pkg.CLTools_Executables and 
>>> /Library/Developer/CommandLineTools/SDKs are related to the Xcode command 
>>> line tools, which are separate from Xcode. So I guess you have the Xcode 
>>> command line tools installed but do not have Xcode installed. For many 
>>> ports, this is fine. For those where it is not, they should tell you to 
>>> install Xcode.
>>> 
>> 
> 

Re: port diagnose and xcode

[xplora]

Is it a Mac Alias, or a unix ln ? (i.e. the former is created with a 
drag-n-drop of the App holding down the Command & Option keys, while the former 
is created with the command ln -s /path/to/app lnfile, and that is a lowercase 
L, not an uppercase i). MacPorts will work better with the latter ln alias, not 
the former finder created alias.

-- 
Richard Smith
xpl...@wak.co.nz




> On 14/03/2022, at 06:41, James Secan  wrote:
> 
> I do have the full Xcode package installed (8.2.1) on the El Capitan system, 
> although I have it as an alias in the Applications directory (on a smallish 
> SSD) linking to the actual Xcode files on an internal HD because it requires 
> a lot of disk real estate and I never use Xcode.  Would that confuse port 
> diagnose?  (I just checked, and if I click on the Xcode alias it works just 
> as one would expect, so the alias linkage is OK.)
> 
> Jim
> 3222 NE 89th St
> Seattle, WA 98115
> (206) 430-0109
> 
>> On Mar 12, 2022, at 6:42 PM, Ryan Schmidt  wrote:
>> 
>> On Mar 10, 2022, at 18:40, James Secan wrote:
>> 
>>> In working my way through my recent “phantom ports” issue I ran the command 
>>> “port diagnose” and was more than a bit surprised by the output line:
>>> 
>>> Error: currently installed version of Xcode, none, is not supported by 
>>> MacPorts.
>>> 
>>> followed by a list of the version supported under my version of macOS (El 
>>> Capitan, in this case).  Where is port getting this information?  I have 
>>> Xcode 8.2.0 installed, and none of my attempts to install ports have run 
>>> into any trouble related to Xcode not being installed.  I ran "pkgutil -v 
>>> --pkg-info=com.apple.pkg.CLTools_Executables” which shows that I have 8.2.0 
>>> installed, and the appropriate MacOSX.sdk files are in 
>>> /Library/Developer/CommandLineTools/SDKs.  I also tried this on my test 
>>> Catalina system, with the same result.
>>> 
>>> Is something wrong with my ports setup?
>> 
>> 
>> Both com.apple.pkg.CLTools_Executables and 
>> /Library/Developer/CommandLineTools/SDKs are related to the Xcode command 
>> line tools, which are separate from Xcode. So I guess you have the Xcode 
>> command line tools installed but do not have Xcode installed. For many 
>> ports, this is fine. For those where it is not, they should tell you to 
>> install Xcode.
>> 
> 

Re: port diagnose and xcode

[James Secan]

I do have the full Xcode package installed (8.2.1) on the El Capitan system, 
although I have it as an alias in the Applications directory (on a smallish 
SSD) linking to the actual Xcode files on an internal HD because it requires a 
lot of disk real estate and I never use Xcode.  Would that confuse port 
diagnose?  (I just checked, and if I click on the Xcode alias it works just as 
one would expect, so the alias linkage is OK.)

Jim
3222 NE 89th St
Seattle, WA 98115
(206) 430-0109

> On Mar 12, 2022, at 6:42 PM, Ryan Schmidt  wrote:
> 
> On Mar 10, 2022, at 18:40, James Secan wrote:
> 
>> In working my way through my recent “phantom ports” issue I ran the command 
>> “port diagnose” and was more than a bit surprised by the output line:
>> 
>> Error: currently installed version of Xcode, none, is not supported by 
>> MacPorts.
>> 
>> followed by a list of the version supported under my version of macOS (El 
>> Capitan, in this case).  Where is port getting this information?  I have 
>> Xcode 8.2.0 installed, and none of my attempts to install ports have run 
>> into any trouble related to Xcode not being installed.  I ran "pkgutil -v 
>> --pkg-info=com.apple.pkg.CLTools_Executables” which shows that I have 8.2.0 
>> installed, and the appropriate MacOSX.sdk files are in 
>> /Library/Developer/CommandLineTools/SDKs.  I also tried this on my test 
>> Catalina system, with the same result.
>> 
>> Is something wrong with my ports setup?
> 
> 
> Both com.apple.pkg.CLTools_Executables and 
> /Library/Developer/CommandLineTools/SDKs are related to the Xcode command 
> line tools, which are separate from Xcode. So I guess you have the Xcode 
> command line tools installed but do not have Xcode installed. For many ports, 
> this is fine. For those where it is not, they should tell you to install 
> Xcode.
> 

Re: port diagnose and xcode

[Ryan Schmidt]

On Mar 12, 2022, at 21:57, Richard L. Hamilton wrote:

> Is there a way one can see by examining Portfiles (ideally something that 
> could be scanned for with e.g. a perl script), or preferably, with some 
> "port" command, which ports require command line tools vs Xcode vs neither 
> (albeit perhaps needing something to get a compiler port installed)?

Ports that require Xcode *to build* contain the line "use_xcode yes". There is 
no port command to see this information. You can use grep (or perl or some 
other tool) to search the Portfiles for this, however it is also possible for 
portgroups to set this, and then any port that uses that portgroup could also 
require Xcode. And Portfiles can use the full features of the Tcl programming 
language; possibly Xcode is only needed in some situations; you'd have to read 
the Portfile to see in what context (globally? in a subport? in a variant? 
based on some other condition?) "use_xcode yes" is specified.

Ports that require a MacPorts-provided compiler *to build* will declare a 
dependency on it. "port echo depends_build:(clang|gcc)" could be a starting 
point for identifying these ports, though you'll probably get false positives; 
not every port whose name contains "clang" or "gcc" is a compiler. And there 
are also compilers other than clang and gcc -- rust for example.

Compiled Mach-O files are architecture-specific. (They are for arm64, or 
x86_64, etc.) Ports that install only files that are not architecture-specific 
contain the line "supported_archs noarch" (or include a portgroup that contains 
that line). So these ports probably don't need a compiler *to build*. But some 
of them might still need other files provided by Xcode or the command line 
tools. There's no way to know without trying to build the port and see what 
happens.

Most of the remaining ports probably need a compiler from Xcode or the Xcode 
command line tools *to build*, though there could also be ports that just 
repackage binaries provided by upstream, in which case they don't need a 
compiler.

And as I said, if you get a binary of the port from MacPorts, then you don't 
need to build it at all, so you don't need any compiler. There are a variety of 
reasons why a binary might not be available. There isn't a port command to 
check in advance whether a binary is available. If you want to know, you can 
check the directory listings at https://packages.macports.org

Re: port diagnose and xcode

[Richard L. Hamilton]

Is there a way one can see by examining Portfiles (ideally something that could 
be scanned for with e.g. a perl script), or preferably, with some "port" 
command, which ports require command line tools vs Xcode vs neither (albeit 
perhaps needing something to get a compiler port installed)?

> On Mar 12, 2022, at 21:47, Ryan Schmidt  wrote:
> 
> On Mar 11, 2022, at 02:02, Michele Venturi wrote:
> 
>> What is wrong is that a simple package manager
>> requires an entire multigigabyte professional IDE;
>> I have even taken the time to talk to them about it
>> and file a bug about it,but they clearly don't care...
>> It's surely not a new issue,it's like that by design...
> 
> MacPorts does not require Xcode.
> 
> Compiling ports requires a compiler and associated files. In most cases the 
> Xcode command line tools are sufficient. A small number of ports cannot build 
> with the CLT and require the full Xcode install. If you try to compile one of 
> these ports and you do not have Xcode installed, you should see a message 
> telling you to install Xcode.
> 
> In many cases, we have already built binaries of ports that MacPorts on your 
> computer will automatically use. In those cases, you do not need a compiler 
> -- you do not need Xcode nor do you need the Xcode command line tools.
> 
> It was recently suggested that our documentation is not clear enough on these 
> points and I believe someone was going to make improvements.
> 
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: port diagnose and xcode

[Ryan Schmidt]

On Mar 11, 2022, at 02:02, Michele Venturi wrote:

> What is wrong is that a simple package manager
> requires an entire multigigabyte professional IDE;
> I have even taken the time to talk to them about it
> and file a bug about it,but they clearly don't care...
> It's surely not a new issue,it's like that by design...

MacPorts does not require Xcode.

Compiling ports requires a compiler and associated files. In most cases the 
Xcode command line tools are sufficient. A small number of ports cannot build 
with the CLT and require the full Xcode install. If you try to compile one of 
these ports and you do not have Xcode installed, you should see a message 
telling you to install Xcode.

In many cases, we have already built binaries of ports that MacPorts on your 
computer will automatically use. In those cases, you do not need a compiler -- 
you do not need Xcode nor do you need the Xcode command line tools.

It was recently suggested that our documentation is not clear enough on these 
points and I believe someone was going to make improvements.

Re: port diagnose and xcode

[Ryan Schmidt]

On Mar 10, 2022, at 18:40, James Secan wrote:

> In working my way through my recent “phantom ports” issue I ran the command 
> “port diagnose” and was more than a bit surprised by the output line:
> 
> Error: currently installed version of Xcode, none, is not supported by 
> MacPorts.
> 
> followed by a list of the version supported under my version of macOS (El 
> Capitan, in this case).  Where is port getting this information?  I have 
> Xcode 8.2.0 installed, and none of my attempts to install ports have run into 
> any trouble related to Xcode not being installed.  I ran "pkgutil -v 
> --pkg-info=com.apple.pkg.CLTools_Executables” which shows that I have 8.2.0 
> installed, and the appropriate MacOSX.sdk files are in 
> /Library/Developer/CommandLineTools/SDKs.  I also tried this on my test 
> Catalina system, with the same result.
> 
> Is something wrong with my ports setup?


Both com.apple.pkg.CLTools_Executables and 
/Library/Developer/CommandLineTools/SDKs are related to the Xcode command line 
tools, which are separate from Xcode. So I guess you have the Xcode command 
line tools installed but do not have Xcode installed. For many ports, this is 
fine. For those where it is not, they should tell you to install Xcode.

Re: port diagnose and xcode

[Joshua Root]

I truly appreciate everyone who maintains things for MP - couldn’t live without 
this stuff.  My initial query was just trying to understand whether ‘port 
diagnose’ was telling me something I should be concerned about.  I think the 
answer was ‘no’.
The message could be improved for that case, certainly. All that check 
does currently is print the message that started this discussion if your 
currently installed version of Xcode is not in the list of versions 
known to work on your OS version: 



If no version of Xcode is installed, it should say something along the 
lines of "You don't have Xcode installed, so you will not be able to 
build the subset of ports that build using Xcode."


It should also check the CLT version but currently doesn't.

- Josh

Re: port diagnose and xcode

[James Secan]

I truly appreciate everyone who maintains things for MP - couldn’t live without 
this stuff.  My initial query was just trying to understand whether ‘port 
diagnose’ was telling me something I should be concerned about.  I think the 
answer was ‘no’.

Jim
3222 NE 89th St
Seattle, WA 98115
(206) 430-0109

> On Mar 11, 2022, at 2:21 PM, Dave Horsfall  wrote:
> 
> On Fri, 11 Mar 2022, Chris Jones wrote:
> 
>> MacPorts is not (just) 'a simple package manager'. Yes, it performs this 
>> function, but first and foremost (and long before we even had binary 
>> tarballs to distribute as a 'package mnager') it is a system for 
>> building packages and their dependencies. To build something you require 
>> a compiler. Many ports will build fine with just the Apple CLT package, 
>> but some indeed require the full Xcode installation in order to be built 
>> (and Xcode also is not just an IDE, but is also a command line build 
>> system).
> 
> I couldn't have put it better myself; the fact that some packages 
> (contributed to MacPorts) require Xcode is hardly MacPorts' fault.
> 
> I dips me lid to the MP maintainers for what is obviously a thankless job.
> 
> -- Dave

Re: port diagnose and xcode

[Dave Horsfall]

On Fri, 11 Mar 2022, Chris Jones wrote:

> MacPorts is not (just) 'a simple package manager'. Yes, it performs this 
> function, but first and foremost (and long before we even had binary 
> tarballs to distribute as a 'package mnager') it is a system for 
> building packages and their dependencies. To build something you require 
> a compiler. Many ports will build fine with just the Apple CLT package, 
> but some indeed require the full Xcode installation in order to be built 
> (and Xcode also is not just an IDE, but is also a command line build 
> system).

I couldn't have put it better myself; the fact that some packages 
(contributed to MacPorts) require Xcode is hardly MacPorts' fault.

I dips me lid to the MP maintainers for what is obviously a thankless job.

-- Dave

Re: port diagnose and xcode

[Chris Jones]

On 11/03/2022 8:02 am, Michele Venturi wrote:

What is wrong is that a simple package manager
requires an entire multigigabyte professional IDE;
I have even taken the time to talk to them about it
and file a bug about it,but they clearly don't care...
It's surely not a new issue,it's like that by design...



MacPorts is not (just) 'a simple package manager'. Yes, it performs this 
function, but first and foremost (and long before we even had binary 
tarballs to distribute as a 'package mnager') it is a system for 
building packages and their dependencies. To build something you require 
a compiler. Many ports will build fine with just the Apple CLT package, 
but some indeed require the full Xcode installation in order to be built 
(and Xcode also is not just an IDE, but is also a command line build 
system).


So yes, if you want to put it in those terms requiring Xcode/CLT is 'by 
design'.




Il ven 11 mar 2022, 01:40 James Secan > ha scritto:


In working my way through my recent “phantom ports” issue I ran the
command “port diagnose” and was more than a bit surprised by the
output line:

Error: currently installed version of Xcode, none, is not supported
by MacPorts.

followed by a list of the version supported under my version of
macOS (El Capitan, in this case).  Where is port getting this
information?  I have Xcode 8.2.0 installed, and none of my attempts
to install ports have run into any trouble related to Xcode not
being installed.  I ran "pkgutil -v
--pkg-info=com.apple.pkg.CLTools_Executables” which shows that I
have 8.2.0 installed, and the appropriate MacOSX.sdk files are in
/Library/Developer/CommandLineTools/SDKs.  I also tried this on my
test Catalina system, with the same result.

Is something wrong with my ports setup?

Jim
3222 NE 89th St
Seattle, WA 98115
(206) 430-0109

 > On Mar 10, 2022, at 12:34 AM, Ryan Schmidt
mailto:ryandes...@macports.org>> wrote:
 >
 > On Mar 9, 2022, at 17:13, James Secan wrote:
 >>
 >> when I run "port upgrade installed -u outdated”
 >
 > This command doesn't make a great deal of sense. You're asking
MacPorts to upgrade the "installed" ports (which includes those
those that are outdated and those that aren't) and also the
"outdated" ports (those that are outdated). It would be simpler and
more efficient to just run "sudo port -u upgrade outdated".
Single-dash/single-letter flags like "-u" go after "port" and before
the action (the action in this case being "upgrade").
 >
 > For completeness, "-u" means "uninstall inactive ports"; if you
want to keep inactive ports, for example as a safeguard so that you
could return to them in case something is wrong with the new
version, then don't use "-u". When you eventually run "sudo port
reclaim", that will get rid of the inactive versions.
 >
 > MacPorts reminds to run "sudo port reclaim" if you have not done
so in a few weeks, unless you have configured MacPorts not to remind
you.

Re: port diagnose and xcode

[Michele Venturi]

What is wrong is that a simple package manager
requires an entire multigigabyte professional IDE;
I have even taken the time to talk to them about it
and file a bug about it,but they clearly don't care...
It's surely not a new issue,it's like that by design...

Il ven 11 mar 2022, 01:40 James Secan  ha scritto:

> In working my way through my recent “phantom ports” issue I ran the
> command “port diagnose” and was more than a bit surprised by the output
> line:
>
> Error: currently installed version of Xcode, none, is not supported by
> MacPorts.
>
> followed by a list of the version supported under my version of macOS (El
> Capitan, in this case).  Where is port getting this information?  I have
> Xcode 8.2.0 installed, and none of my attempts to install ports have run
> into any trouble related to Xcode not being installed.  I ran "pkgutil -v
> --pkg-info=com.apple.pkg.CLTools_Executables” which shows that I have 8.2.0
> installed, and the appropriate MacOSX.sdk files are in
> /Library/Developer/CommandLineTools/SDKs.  I also tried this on my test
> Catalina system, with the same result.
>
> Is something wrong with my ports setup?
>
> Jim
> 3222 NE 89th St
> Seattle, WA 98115
> (206) 430-0109
>
> > On Mar 10, 2022, at 12:34 AM, Ryan Schmidt 
> wrote:
> >
> > On Mar 9, 2022, at 17:13, James Secan wrote:
> >>
> >> when I run "port upgrade installed -u outdated”
> >
> > This command doesn't make a great deal of sense. You're asking MacPorts
> to upgrade the "installed" ports (which includes those those that are
> outdated and those that aren't) and also the "outdated" ports (those that
> are outdated). It would be simpler and more efficient to just run "sudo
> port -u upgrade outdated". Single-dash/single-letter flags like "-u" go
> after "port" and before the action (the action in this case being
> "upgrade").
> >
> > For completeness, "-u" means "uninstall inactive ports"; if you want to
> keep inactive ports, for example as a safeguard so that you could return to
> them in case something is wrong with the new version, then don't use "-u".
> When you eventually run "sudo port reclaim", that will get rid of the
> inactive versions.
> >
> > MacPorts reminds to run "sudo port reclaim" if you have not done so in a
> few weeks, unless you have configured MacPorts not to remind you.
>
>