vcvrack: new port

[herbygillot]

New port for VCVRack

• Closes: https://trac.macports.org/ticket/58900

Description

Tested on

macOS 10.15.6 19G73
Xcode 11.6 11E708

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL?

• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?

[macportsbot]

Travis Build #13183 Passed.

Lint results

--->  Verifying Portfile for vcvrack
--->  0 errors and 0 warnings found.

Port vcvrack success on xcode10.3. Log
Port vcvrack success on xcode9.4. Log
Port vcvrack success on xcode8.3. Log
Port vcvrack fail on xcode7.3. Log

[kencu]

will need thread_local:

src/random.cpp:14:1: error: thread-local storage is not supported for the current target
thread_local uint64_t xoroshiro128plus_state[2];
^

I think this has been finally fixed in the new base, so if we're lucky, you can just add it with a compiler spec now.

[herbygillot]

will need thread_local:

src/random.cpp:14:1: error: thread-local storage is not supported for the current target
thread_local uint64_t xoroshiro128plus_state[2];
^

I think this has been finally fixed in the new base, so if we're lucky, you can just add it with a compiler spec now.

OK, thanks. Trying with compiler.thread_local_storage yes, let's see if that helps any.

[macportsbot]

Travis Build #13192 Passed.

Lint results

--->  Verifying Portfile for vcvrack
--->  0 errors and 0 warnings found.

Port vcvrack success on xcode10.3. Log
Port vcvrack success on xcode9.4. Log
Port vcvrack success on xcode8.3. Log
Port vcvrack fail on xcode7.3. Log

[kencu]

well, now we see the next problem! It's not UsingTheRightCompiler:

c++ -std=c++11 -stdlib=libc++  -DVERSION=1.1.6 -Iinclude -Idep/include -MMD -MP -g -O3 -march=nocona -funsafe-math-optimizations -Wall -Wextra -Wno-unused-parameter -DARCH_MAC -mmacosx-version-min=10.7  -c -o build/src/random.cpp.o src/random.cpp
src/random.cpp:14:1: error: thread-local storage is not supported for the current target
thread_local uint64_t xoroshiro128plus_state[2];
^
1 error generated.

so it has ignored your nice compiler spec...

[herbygillot]

Trying one more time...

[macportsbot]

Travis Build #13194 Passed.

Lint results

--->  Verifying Portfile for vcvrack
--->  0 errors and 0 warnings found.

Port vcvrack success on xcode10.3. Log
Port vcvrack success on xcode9.4. Log
Port vcvrack success on xcode8.3. Log
Port vcvrack's dependencies fail on xcode7.3. Log

[macportsbot]

Travis Build #13196 Passed.

Lint results

--->  Verifying Portfile for vcvrack
--->  0 errors and 0 warnings found.

Port vcvrack success on xcode10.3. Log
Port vcvrack success on xcode9.4. Log
Port vcvrack success on xcode8.3. Log

[herbygillot]

Trying another approach, incorporating the makefile portgroup.

[herbygillot]

Nevermind. Reverting changes.

[macportsbot]

Travis Build #13209 Failed.

Lint results

--->  Verifying Portfile for vcvrack
--->  0 errors and 0 warnings found.

Port vcvrack fail on xcode10.3. Log
Port vcvrack fail on xcode9.4. Log
Port vcvrack fail on xcode8.3. Log

[macportsbot]

Travis Build #13216 Passed.

Lint results

--->  Verifying Portfile for vcvrack
--->  0 errors and 0 warnings found.

Port vcvrack success on xcode10.3. Log
Port vcvrack success on xcode9.4. Log
Port vcvrack success on xcode8.3. Log
Port vcvrack fail on xcode7.3. Log

[kencu]

To my very great disappointment, despite adding compiler.thread_local_storage yes we still wind up with a compiler that does not support thread_local_storage.

[herbygillot]

To my very great disappointment, despite adding compiler.thread_local_storage yes we still wind up with a compiler that does not support thread_local_storage.

It could just be that the way the Makefile is structured, it's ignoring what MacPorts is trying to do. I haven't dug in myself, but tbh I think we're not bad for 3 out of 4 XCode versions 😂

[herbygillot]

Or also perhaps in the way we're invoking make, as we have to use manually specified build steps instead of the default build command, env and args as would be provided by MacPorts default.

[kencu]

luckily that is easy to test...just force a compiler.

[ryandesign]

To my very great disappointment, despite adding compiler.thread_local_storage yes we still wind up with a compiler that does not support thread_local_storage.

Only because our Travis CI build process has not been updated to use MacPorts 2.6.3. https://trac.macports.org/ticket/60925

[ryandesign]

Does it use autoconf, automake, python38? I didn't see it in the log, but it is downloading and building lots of other dependencies and is using silent rules so the exact commands it's running aren't always visible.

[herbygillot]

You're right, I removed those and the build still completed. Will see how it fares in CI.

[ryandesign]

And jq? I see it is mentioned in the building instructions. I don't see it used in the log but maybe it is still used in some way that isn't shown in the log.

[herbygillot]

jq is indeed used by one of the dependencies that gets pulled in, "jpommier".

[macportsbot]

Travis Build #13362 Passed.

Lint results

--->  Verifying Portfile for vcvrack
--->  0 errors and 0 warnings found.

Port vcvrack success on xcode10.3. Log
Port vcvrack success on xcode9.4. Log
Port vcvrack success on xcode8.3. Log

[ryandesign]

Would it make sense to have a separate vcvrack-fundamental port that vcvrack would depend on? That way it could have its own version number, could be updated independently of vcvrack, could use a normal distfile which could be mirrored, etc.

[herbygillot]

I had that passing thought, but the problem is that the Fundamental plugins have no place on the installed filesystem.

They are only meant as extra source files going into vcvrack's build process. If I make them a sub-port then they will have to be installed somewhere in the formal filesystem - but once vcvrack is built and packaged, they serve no further purpose after that....

Then again I suppose that's the entire point of `depends_build, I guess 😅

[ryandesign]

They are only meant as extra source files going into vcvrack's build process

Oh I didn't realize that. I just saw the code in the portfile that just seemed to be fetching the fundamental distfile, verifying checksums, extracting, and then creating a new zip file. I assumed that new zip file was being installed as is. I didn't realize the build process was unpacking it again and building it. I wonder why they make you create a new zip file rather than using the one that was downloaded.

[herbygillot]

Basically the way it works is that Rack can build plugins against its source. There are the set of "fundamental" plugins, and then others/3rd-party.

The fundamental plugins are downloaded as a zip file containing source, extracted into place in the source tree, and after the first phase of Rack's build process, the plugins are then built against the libs and assets of Rack. Afterwards the resulting objects and dylibs (and source code, manifest JSON and what-have-you) are zipped up again and placed into the resulting .app bundle for vcvrack.

When the user first double-clicks on the app, Rack creates a user directory in ~/Documents, and extracts the built fundamentals zip into a plugins subdirectory there.

[ryandesign]

Well thanks for figuring this all out. A friend of mine has been raving about the wonders of the Eurorack so I'll have to try this port.

[herbygillot]

No worries. The one thing this is missing is the SDK, which I'll add at some later point in time. The vcvrack SDK is necessary to build additional plugins for Rack which also get installed to the user plugins directory.