Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#59798 closed enhancement (fixed)

base should always set ${configure.sdkroot} and $env(SDKROOT) to some value, even, in the end "/".

Reported by: kencu (Ken) Owned by: jmroot (Joshua Root)
Priority: Normal Milestone:
Component: base Version:
Keywords: Cc: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), jmroot (Joshua Root), majoc-at-astro (majoc-at-astro)
Port:

Description

${configure.sdkroot} and SDKROOT should always ultimately be set to some value by base, even, in the end "/".

These variables are used for logic in various Portfiles, shell scripts, and by xcrun/clang.

Otherwise, innumerable Portfiles need to test for ${configure.sdkroot} == "" and then set these values themselves, which seems a needless duplication of work that belongs in base.

Change History (13)

comment:1 Changed 4 years ago by kencu (Ken)

Resolution: wontfix
Status: newclosed

comment:2 Changed 4 years ago by kencu (Ken)

Resolution: wontfix
Status: closedreopened
Last edited 4 years ago by kencu (Ken) (previous) (diff)

comment:3 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

In the pull request, Joshua objected to the change, saying:

This breaks usage to construct paths like ${configure.sdkroot}/usr/include/foo.h.

I do not understand the objection. In what way does that break?

comment:4 Changed 4 years ago by jmroot (Joshua Root)

Some numbers for your consideration:

  • 108 Portfiles in the tree look at ${configure.sdkroot}.
  • Of those, only 20 set it to /. The rest do something else when it is empty.

Yes, technically the double slash doesn't break that example because double slashes happen to be interpreted the same as a single slash in paths. However, no SDK is a different thing to an SDK that is located at /. An empty configure.sdkroot means we don't add any -isysroot to the compiler flags.

comment:5 Changed 4 years ago by kencu (Ken)

I am now quite curious what these ports would be setting it to, if MacPorts base has worked out it should be "/" (and is therefore leaving it empty at present). At first blush, I can only imagine they must be setting it incorrectly, but will check.

comment:6 Changed 4 years ago by jmroot (Joshua Root)

They're not changing it, because it's correct.

comment:7 Changed 4 years ago by majoc-at-astro (majoc-at-astro)

Cc: majoc-at-astro added

comment:8 Changed 4 years ago by kencu (Ken)

I see.

So software should by default always use "/" if no SDKROOT or configure.sdkroot or isysroot (etc) has been set, therefore telling them to do so by setting SDKROOT to "/" is inherently wrong, and the software should be fixed upstream not to need to do that.

At least I think I see your point now, if that is it.

comment:9 Changed 4 years ago by kencu (Ken)

You know, that's actually fair enough, if that's the way you feel MacPorts should leave it.

Our trouble seems to be from software that goes off trying to find it's own SDKROOT if the user hasn't specified one during configuration. For MacPorts, they are almost always doing it wrong.

If you feel that the right thing to do here is to set the configure.sdkroot to "/" (if appropriate) for those ports only, on a port-by-port as we come across them basis, and that approach will reduce problems, that's actually fine by me.

Last edited 4 years ago by kencu (Ken) (previous) (diff)

comment:10 Changed 3 years ago by kencu (Ken)

Resolution: wontfix
Status: reopenedclosed

I believe the conclusion of all this is "wontfix"

comment:11 Changed 3 years ago by jmroot (Joshua Root)

If you want to add a separate variable that always contains a path, that's also fine.

comment:12 Changed 3 years ago by jmroot (Joshua Root)

Owner: set to jmroot
Resolution: wontfixfixed

In 8d76ba613f957f33edb0fc6de6501c9f32764f62/macports-base (master):

Add configure.sysroot variable

This is based on configure.sdkroot and contains either the path to the
SDK, or '/' if no SDK is in use, so it can be used in contexts where a
valid filesystem path where system headers and libraries can be found
is always needed.

Fixes: #59798

comment:13 Changed 3 years ago by kencu (Ken)

Thanks Josh -- I see what you were after here now.

Note: See TracTickets for help on using tickets.