std::filesystem::path is not supported in macOS<10.15 about neuralampmodelerplugin

[Moonheadmix]

Looking forward to a fix to be able to use in Mojave thank you

[mikeoliphant]

I think it would be better to just pass paths as strings, rather than add another dependency with https://github.com/gulrak/filesystem.

From looking at the code, it isn't doing much specific to std::filesystem::path beyond some file existence checks.

[masqutti]

I think it would be better to just pass paths as strings, rather than add another dependency with https://github.com/gulrak/filesystem.

From looking at the code, it isn't doing much specific to std::filesystem::path beyond some file existence checks.

One idea would be to just assimilate gulrak's filesystem to this repo without a submodule as it work well as for now... :P but I don't know what harm there'd be to add a submodule as they're already used extensively in this one!

On a side-note, iPlug2 removed the only lines that made it C++17 only, which is really cool! :) ( iPlug2/iPlug2@bc5aae0 )

[masqutti]

masqutti@e3fa057

Here's info how I did it, it's not a big change but I am unfortunately too occupied at the moment to do pull requests myself. It requires the https://github.com/gulrak/filesystem to exist and subfolder "Include" added as to header search paths to allow building. Also iPlug2 needs two small changes in couple of places (you will notice when you try to build) which are about Structured bindings (not possible with C++14) and very easy to fix, probably ideal to have iPlug2 issue / pull request about them since compiler only complained about 2 lines.

I've confirmed this to work on Windows 10 but not yet on MacOS.

[masqutti]

Did some research on this and based on https://en.cppreference.com/w/cpp/filesystem std::filesystem originally was a feature of boost library so https://www.boost.org/doc/libs/1_81_0/libs/filesystem/doc/index.htm ... Maybe include that in the project instead for backwards compatibility? Or then go with some native route. :)

[sdatkinson]

Might be able to solve this using WDL_Strings from iPlug2.

[sdatkinson]

Drawback would be that the dsp module would be locked into iPlug2, which would be bad.

[masqutti]

Just found this which might be helpful! https://github.com/gulrak/filesystem

"An implementation of C++17 std::filesystem for C++11 /C++14/C++17/C++20 on Windows, macOS, Linux and FreeBSD."

[Gordonozzy]

Mojave 10.14 user—Curious if this is still in progress? Thanks

[masqutti]

Just found this which might be helpful! https://github.com/gulrak/filesystem

"An implementation of C++17 std::filesystem for C++11 /C++14/C++17/C++20 on Windows, macOS, Linux and FreeBSD."

According to my tests gulrak's library is a single-header with handy macro helpers and I managed to build nam plugin with it and C++14. Unfortunately it seems that iPlug2 still requires C++17 but there was just a couple of lines to fix so that built with C++14 too.

[masqutti]

Oh yes definitely, if strings are enough. I guess I'll investigate it a bit further when I got the time 🤔

[masqutti]

I took a look and yes many of the paths can be just std::strings. However there are some std::filesystem methods that are required to be implemented "locally" which are:

has_filename()
stem()
parent_path()
filename()

[EchoReverbFilter]

期待能够在 Mojave 中使用的修复程序，谢谢
me 2, really want try NAM on MAC 10.14 Mojave ! if that works someday, please tell me . thank u !

[EchoReverbFilter]

me 2, really want try NAM on MAC 10.14 Mojave ! if that works someday, please tell me . thank u !

sorry i dont know anything about coding.... im not a geek but really apreaciate ur work , hope u cant work it out ! really want try NAM on MAC 10.14 Mojave ! if that works someday, please tell me . thank u !

[Vladzibor]

Oh, what a pity that the plugin does not work in MOJAVE 10.14.6 Millions of users still work in this operating system. Especially in such difficult times.