CI: Move from Travis-CI to Github Actions #215
Conversation
|
I had no problem building with GCC on macOS (never even tried Xcode). If I understand correctly macOS comes with a GCC version. In my case /usr/bin/gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/binAlternativly, there is also the option to get GCC via Homebrew. That version currently is brew info gcc
gcc: stable 10.2.0 (bottled), HEAD
GNU compiler collection
https://gcc.gnu.org/
/usr/local/Cellar/gcc/10.2.0 (1,463 files, 338.7MB) *
Poured from bottle on 2020-09-03 at 21:44:24
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/gcc.rb
License: GPL-3.0
==> Dependencies
Required: gmp ✔, isl ✔, libmpc ✔, mpfr ✔Is there anything that I can do in terms of testing in case you want to integrate a GCC build path for macOS back into the CI? |
|
BTW, I think I built with the shipped macOS version of GCC, due to not closely paying attention to which one is used. I don't know if is recommended to use the (I assume more recent) Homebrew version. Or if that makes a difference in terms of building / usability experience. |
|
Thanks for following up on this!
All the tested Xcode versions actually call To show that, I included this section: ssr/.github/workflows/main.yml Lines 112 to 117 in 9e2b019 To use the real GCC, I guess you can specify some custom The version check will then show something like this: These versions are already installed on the macOS images that are used. I think the closest I got was this version: https://github.com/mgeier/ssr/blob/4033b1ef2c85f5fbc8611568eecc33397a1ceada/.github/workflows/main.yml These are the (failing) logs: https://github.com/mgeier/ssr/runs/1134236929 And most interestingly, this is the More specifically, this error appears when trying to link with To me, this looks like incompatible standard libraries between It would be great if you could make that work! |
Ah, I see. Isn't that the recommended way to build on macOS then and we should try to make that work (and not with GCC from another source?
I suppose it is worth a try to find a configuration for main.yml which utilizes the builtin |
I don't know. I guess so.
It does. I just thought maybe somebody wants to use GCC for some reason, then we can show how that can be done. But it's not important. As I wrote at the very top: "If not, it's not a problem, I guess most people use Xcode anyway."
Exactly. That's why I was talking about
Well,
There are several Xcode versions, all using ssr/.github/workflows/main.yml Lines 38 to 54 in 9e2b019
Sure, |
|
Ah, I just realized that building with I will try to replicate your approach of configuring and building with |
|
Modifying my given configuration in this way: export CC="gcc-10"
export CXX="g++-10"
export CPATH="/usr/local/include"
export LIBRARY_PATH="/usr/local/lib"I am able to pass I have no idea what to take from the error. The link to |
How was it not recognized?
Your command contains The problem seems to be that some symbols (with the given mangling) don't seem to be in there. Since those symbols seem to be related to My hypothesis is that your You could try to compile Same for |
The respective lines are: config.logActually I only noticed now that it fails in a similar fashion for
Possible.
I could try that if it helps to potentially solve this problem?
Not sure. I think I've tried to build In any case, this seems like a lot of effort for an alternative build path, considering that the solution with Xcode is very straight forward. Would it even be possible (or reasonable) to recreate manual builds of potentially multiple dependencies in the CI? Do you think its still worth trying to make this path work or do we abbandon it as being too convoluted? |
|
i don't have any opinion, but:
well the problem is that if you were to include |
|
Thanks @umlaeute for your input!
Well there kinda is a library version of the SSR, as each renderer can already be used as a library (as shown in the Pd external and MEX file). However, those are header-only libraries, so they will not be distributed in binary form, circumventing the whole problem. We would probably have similar problems when distributing the SSR as Pd externals (which is a work in progress), but I guess in this case we would statically link all libraries, avoiding any compatibility problems. I haven't really looked into that yet, though. Just out of curiosity, I've tried to compile I've managed to build Those two can be compiled like this:
It sure would be possible, we would just add several more It would definitely be quite a bit more complicated, and the config file is already sufficiently complicated for my taste.
IMHO we can drop it for now. If and when somebody needs it (for whatever reason), we can resume our efforts. Thanks for working on this, though! |
I also tried using GCC on macOS, but didn't manage to make it work (because of linker errors probably caused by incompatible standard libraries).
If somebody has an idea how to use GCC, please let me know.
If not, it's not a problem, I guess most people use Xcode anyway.