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

[kencu (Ken)]

${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.

[kencu (Ken)]

was <​https://github.com/macports/macports-base/pull/183>

[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?

[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.

[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.

[jmroot (Joshua Root)]

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

[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.

[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.

[kencu (Ken)]

I believe the conclusion of all this is "wontfix"

[jmroot (Joshua Root)]

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

[jmroot (Joshua Root)]

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

[kencu (Ken)]

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