freetype-devel
[Top][All Lists]
Advanced

[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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]