[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gitlab CI for macOS, both of "autotool gcc" & "autotool clang" are requi
From: |
suzuki toshiya |
Subject: |
gitlab CI for macOS, both of "autotool gcc" & "autotool clang" are required? |
Date: |
Tue, 8 Nov 2022 13:11:10 +0900 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 |
Hi,
In the recent Xcode (a genuine SDK for macOS) by Apple, the command "gcc" is an
alias of clang, there is no real GNU C compiler.
Although I've not checked whether its behaviour can be changed by its invocation name (the case which clang is invoked
as "clang", and the case which clang is invoked as "gcc"), I'm afraid that the current 2 jobs in
"macos autotool" and "macos autotool clang" have no essential difference. Considering the
gitlab.freedesktop.org CI jobs for macOS often have long queue in comparison with for Linux or for Windows, should we
drop one job from these 2?
--
Another idea is an introduction of "autotool gcc" to use real GNU C compiler,
by installing gcc by homebrew, but there are 2 headaches.
1) the macos instance on gitlab.freedesktop.org has a several manual installations in /usr/local, without the
help of homebrew. The root privilege is needed to overwrite them, but the homebrew prohibits to be executed as
root. For detail, please find the log how "brew install gcc" fails at
https://gitlab.freedesktop.org/mpsuzuki/freetype-mps-wip/-/jobs/31170940#L476 . Therefore, we have to introduce a
dirty workaround. In my preliminary draft, make homebrew try to install xz, and ignore its return code (failure),
and gather the list of the files & directories to be overwritten, and execute "sudo chmod ugo+w" to
the listed files. I feel it is quite ugly (I cannot guarantee the stability of the error message format of
homebrew, so the stability of the error message parsing technique is quite suspicious), but slightly safer than
"sudo chmod ugo+w /usr/local/*".
2) homebrew provides a meta-package "gcc", which (might) install the latest version of gcc, but the
installed gcc command has a version suffix, like, gcc-12, gcc-11, ... Therefore, we have to introduce a dirty
workaround. In my preliminary draft, after the installation of "gcc", parse the output of the
command "brew list --version gcc" and obtain the version suffix. As far as their versioning rule is
gcc-${gcc_major_version_integer}, it would work, I hope.
I filed preliminary patch at:
https://gitlab.freedesktop.org/mpsuzuki/freetype-mps-wip/-/commit/674246b4d4bd80afa5b0e3dd0079d133248d7bd2
, but still I'm unsure whether it's worthful to spend the CI resource of
freedesktop.org.
Regards,
mpsuzuki
P.S.
(*) Please do not ask to use the installation to the non-default directory,
like, /opt/homebrew or ${HOME}/homebrew etc. As you know, gcc has many
hardwired directory information, so the installation to the non-default
directory requires the full build of the gcc itself. Spending much CPU time to
build gcc before freetype is clearly bad decision. Providing a prebuilt gcc
binary in the non-default directory independently from homebrew would be
better, but who would care for the result by such homegrown gcc binary?
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- gitlab CI for macOS, both of "autotool gcc" & "autotool clang" are required?,
suzuki toshiya <=