MacOS version

[digitalbox94]

MacOS version is compiling fine with 2 adjustments : are PR accepted to fix such issue ?

-TEMPLATE = vcapp
+TEMPLATE = app

-CONFIG += c++20
+CONFIG += c++17

[gavrant]

I wonder what is the problem with C++ 20 on MacOS? Is it the compiler of your choice yet to support that standard? Or is it something else?

[digitalbox94]

When using c++20, I have the below error :
src/gl/glmesh.cpp:276:23: error: no member named 'make_unique' in namespace 'std'
auto tempMdl = std::make_unique( this );

Checking the compiler version, I can see this version :
Apple clang version 15.0.0 (clang-1500.3.9.4)

[gavrant]

15.0.0 looks pretty outdated for LLVM clang, the latest version is 18.1.8. Though, to be fair, I know nothing about the difference between "Apple clang" and "vanilla (LLVM) clang". I just think that "fixing" clang is a better option here than going back to C++ 17.

[digitalbox94]

15.0.0 looks pretty outdated for LLVM clang, the latest version is 18.1.8. Though, to be fair, I know nothing about the difference between "Apple clang" and "vanilla (LLVM) clang". I just think that "fixing" clang is a better option here than going back to C++ 17.

Ok I've updated clang with homebrew and it's now with version 18.1.8

I've added these lines in the pro file :
QMAKE_CC = /usr/local/opt/llvm/bin/clang
QMAKE_CXX = /usr/local/opt/llvm/bin/clang++
INCLUDEPATH += /usr/local/opt/llvm/include

However qmake is applying automatically some defaulting on the "std" options as per below :
CONFIG += c++20 => -std=gnu++11 => error is still there on MacOS
CONFIG += c++17 => -std=gnu++1z => OK on MacOS

Not sure what this mapping of the CONFIG means and if it's correct, but for the moment II need to use c++17

[DigitalBox98]

Oh and I’m using qt 5.12.x so maybe that’s why this mapping is not good ? (I need to check how the update to 5.15 can be done )

[gavrant]

CONFIG += c++20 => -std=gnu++11 => error is still there on MacOS
CONFIG += c++17 => -std=gnu++1z => OK on MacOS

I’m using qt 5.12.x

Oh, I think I know what's going on! My guess is: if qmake (the Qt tool you used to create a clang makefile from NifSkope.pro) is that outdated, it doesn't know about C++20, considers it a bad option value and defaults the makefile to C++11. So yes, updating Qt looks like the way to go.

[DigitalBox98]

It makes sense, I will try to update to 5.15 to have the good qmake version :)

Thanks !

[digitalbox94]

Ok I've upgraded to QT 5.15 with latest qmake and I've got this version compiling & running fine on MacOS latest version.

However I don't know why but c++20 is not recognized and instead I have to use c++2a for the CONFIG. Plus a few additional adjustements below :

Below are the changes for the pro file :
TEMPLATE = app
QMAKE_CC = /usr/local/opt/llvm/bin/clang
QMAKE_CXX = /usr/local/opt/llvm/bin/clang++
INCLUDEPATH += /usr/local/opt/llvm/include
CONFIG += c++2a
QMAKE_CFLAGS = -fno-define-target-os-macros
ICON = nifskope.icns # addition of an icon for MacOS

Below are the changes for the NifSkope_targets.pri :
f(!isEmpty(dot)) {
exists($$dot) {
HAVE_DOT = YES
DOT_PATH = $$re_escape($${dot})
}
}

Can I submit a PR for that ?

With macdeployqt I've been able to produce also a DMG image for Nifskope (xml files must be copied into the NifSkope.app/Contents/MacOS folder before)

[gavrant]

What version of Qt 5.15 you upgraded to? In your compiled NifSkope, what version is reported in "About Qt" from Help menu? That "c++2a" makes me think that your Qt is still 2 or more years old.

If you submit your changes as PR, will it break NifSkope.pro for all other systems and compilers other than LLVM clang on MacOS? I'm asking because:

• TEMPLATE = app - won't work for Microsoft C++ (Visual Studio) on Windows. vcapp is in the current NifSkope.pro exactly because of VS.
• The vars below are hardcoded to the clang paths on your system. Shouldn't they be outside of the .pro file, in your local bash script instead?
  QMAKE_CC = /usr/local/opt/llvm/bin/clang
QMAKE_CXX = /usr/local/opt/llvm/bin/clang++
INCLUDEPATH += /usr/local/opt/llvm/include
• CONFIG += c++2a - I still believe that "c++20" should remain there because I've been compiling NifSkope with it for a year (on Windows though) without issues.
• QMAKE_CFLAGS = -fno-define-target-os-macros - is it connected to zlib not compiling on MacOS?
• ICON = nifskope.icns - another thing exclusive to MacOS?

Regarding NifSkope_targets.pri and the "dot" thing - just skip building the whole doxygen part if you can. NifSkope is functional without it.

[fo76utils]

Can I submit a PR for that ?

For what it is worth, I merged your changes to my fork here, although I cannot test them, because I only have Linux and Windows PCs. I did make a few modifications:

• I set TEMPLATE = vcapp only for MSVC, and 'app' for everything else.
• Removed the -fno-define-target-os-macros workaround, since I do not use zlib.
• Moved the icon file to res/.
• I also had problems with the same part of NifSkope_targets.pri in the past, so I already changed that code, but in a different way.

[gavrant]

I adjusted the default value of TEMPLATE in my fork too.

That fno-define-target-os-macros is connected to zlib is my guess based on "cmake doesn't compile with clang 18 due to deprecated macros in zutil.c and gzguts.h" being the first result if I search for "fno-define-target-os-macros" on Google. And that thread promises that this problem is fixed in cmake 3.30. Can't verify if it's true or even related. BTW, in my fork. a year ago I updated zlib, so it may help too.

[digitalbox94]

I adjusted the default value of TEMPLATE in my fork too.

That fno-define-target-os-macros is connected to zlib is my guess based on "cmake doesn't compile with clang 18 due to deprecated macros in zutil.c and gzguts.h" being the first result if I search for "fno-define-target-os-macros" on Google. And that thread promises that this problem is fixed in cmake 3.30. Can't verify if it's true or even related. BTW, in my fork. a year ago I updated zlib, so it may help too.

Ok for the TEMPLATE adjustment

Regarding the fno-define-target-os-macros yes it's linked to zlib compilation failing on MacOS.

I've upgraded cmake to version 3.30.2 but it still failing ( In file included from lib/zlib/gzguts.h:21:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk/usr/include/stdio.h:220:7: error: expected ')' )

I will check for all the other comments above and test them :)

[digitalbox94]

• QMAKE_CC = /usr/local/opt/llvm/bin/clang
QMAKE_CXX = /usr/local/opt/llvm/bin/clang++
INCLUDEPATH += /usr/local/opt/llvm/include

Ok please find below my findings :

• QMAKE_CC / QMAKE_CXX / INCLUDEPATH: I've done an EXPORT of these variables outside of Nifskope.pro before launching qmake and make, but I don't know why it's not handled correctly. So clang/clang++ with latest version from homebrew is not taken into account (only clang/clang++ from Xcode). So compilation is still failing.
• CONFIG += c++20 : on MacOS I don't know why but it's producing with qmake the option "-std=gnu++11" which is then make the compilation failing
• ICON = nifskope.icns : yes this is only to have an icon of the application on MacOS

These options relative to Mac are handled with the command "macx" like below so that it doesn't disturb other platforms :
macx: {
QMAKE_CFLAGS = -fno-define-target-os-macros
}

I've put the PR here #87 but it might need some adjustments

[digitalbox94]

Can I submit a PR for that ?

For what it is worth, I merged your changes to my fork here, although I cannot test them, because I only have Linux and Windows PCs. I did make a few modifications:

• I set TEMPLATE = vcapp only for MSVC, and 'app' for everything else.
• Removed the -fno-define-target-os-macros workaround, since I do not use zlib.
• Moved the icon file to res/.
• I also had problems with the same part of NifSkope_targets.pri in the past, so I already changed that code, but in a different way.

Ok I've tried to compile this fork and I have this result :

Everything is compiling fine except the file mesh.cpp for the below line

src/spells/mesh.cpp:1732:63: error: redefinition of parameter 'v'
 1732 |                                                 Triangle        t( quint16(v[p[0]]), quint16(v[p[1]]), quint16(v[p[2]]) );
      |                                                                                                                ^
src/spells/mesh.cpp:1732:27: note: previous declaration is here
 1732 |                                                 Triangle        t( quint16(v[p[0]]), quint16(v[p[1]]), quint16(v[p[2]]) );
      |                                                                            ^

I guess an adjustment is needed on the way v[] is used

[gavrant]

CONFIG += c++20 : on MacOS I don't know why but it's producing with qmake the option "-std=gnu++11" which is then make the compilation failing

I believe you still call the old qmake. It could be even your original 5.12.x (I guess, it's new enough to know about "c++2a"). What version of Qt is reported in your compiled NifSkope, Help menu, "About Qt"?

Also, just in case, if you have .qmake.stash file in your copy of NifSkope source code, try deleting it before running qmake next time. It appears to be a cash file for Qt, could be the culprit.