[MacPorts] #55471: Use separate portindexes for libc++ on older systems

[MacPorts]

#55471: Use separate portindexes for libc++ on older systems
--------------------------+-----------------
  Reporter:  ryandesign   |      Owner:
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+-----------------

Comment (by ryandesign):

 Replying to [comment:3 mojca]:
 > Modifying the following chunk of code of `mprsyncup` seems trivial:

 You did see the attached patches, where I already made the modifications?

 > it kind of looks like a bad idea to try to squeeze `_libc++` into
 `10_i386` as in
 > {{{
 > portindex -p macosx_10_libcxx_i386
 > }}}
 > and break indexing.

 What do you mean, "break indexing"?

 > Maybe something like
 > {{{
 > portindex -p macosx_10_i386 -stdlib libc++
 > }}}
 > or (less ideal)
 > {{{
 > portindex -p macosx-libc++_10_i386
 > }}}
 > would be a better fit?

 I did consider and did initially implement a `-stdlib` flag, before
 deciding that I liked it better next to the OS version number. The stdlib
 is no less a part of the PortIndex identification than the OS name,
 version, or arch; since those three don't have individual flags, I didn't
 think we should add a separate flag for stdlib.

 > I also wouldn't really mind having a directory structure like this one:
 > {{{
 >     PortIndex_darwin_8_i386
 >     PortIndex_darwin_8_i386/libc++
 >     PortIndex_darwin_8_powerpc
 >     PortIndex_darwin_8_powerpc/libstdc++
 >     PortIndex_darwin_9_i386
 >     PortIndex_darwin_9_i386/libc++
 >     PortIndex_darwin_9_powerpc
 >     PortIndex_darwin_9_powerpc/libstdc++
 > }}}
 > if that doesn't bring too many additional complications for generating
 the tarballs or calling selfupdate (one can exclude folders when using
 rsync).

 I had not considered this. But again, I see the stdlib as no less
 important to the description of the PortIndex than the other three
 components, so I would not demote one to a subdirectory.

 > While at it: why do we have a separate `portindex` for `powerpc`, but
 not for `x86_64`?

 "x86_64" is not a valid value for `os.arch`. The only valid values are
 `powerpc` (meaning any 32-bit or 64-bit PowerPC processor) and `i386`
 (meaning any 32-bit or 64-bit Intel processor).

 > One further question. While writing some `Portfiles` I remember
 experiencing problems by not being able to tell the difference between the
 globally set stdlib and the one that could have come from a PortGroup. I
 hope that won't be a problem for `Portindex`, I need to check.

 If I remember correctly, there is `cxx_stdlib` (the value set in
 macports.conf; ports and portgroups should not use this) and
 `configure.cxx_stdlib` (which defaults to `cxx_stdlib` but which ports and
 portgroups can override as needed). My patches have `portindex` change the
 value of `cxx_stdlib` when so requested, and ports like those mentioned in
 comment:1 that want to override it still can.

--
Ticket URL: <https://trac.macports.org/ticket/55471#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS