[Soc-coordination] Report 2 - Clang for build services

Alexander Pashaliyski al.pashaliyski at gmail.com
Sun Jul 1 22:28:13 UTC 2012


I wrote a function for parsing debian/rules file that is looking for hard-coded compiler there ( step 6 from our plan ). If there is a hard-coded compiler, which is different from the one chosen as a default, the building proccess exits with a clear error:
────────────────────────────────────────────────────────────────────────────────
Hard-coded compiler in debian/rules !
There is a hard-coded compiler in debian/rules, but the default compiler is clang!
CC =gcc
  CC =$(DEB_HOST_GNU_TYPE)-gcc
  CC =diet -v -Os gcc
────────────────────────────────────────────────────────────────────────────────

In the building proccess I write in the metadata of the package which compiler is used for building.
Currently I assume that the default compilers are presented as /usr/bin/cc and /usr/bin/c++.
Me and my mentor are talking about using update-alternatives for choosing default compiler:

root at debian:~/changes/dpkg# update-alternatives --config cc
There are 2 choices for the alternative cc (providing /usr/bin/cc).

  Selection    Path            Priority   Status
------------------------------------------------------------
  0            /usr/bin/gcc     20        auto mode
* 1            /usr/bin/clang   10        manual mode
  2            /usr/bin/gcc     20        manual mode

root at debian:~/changes/dpkg# update-alternatives --config c++
There are 2 choices for the alternative c++ (providing /usr/bin/c++).

  Selection    Path              Priority   Status
------------------------------------------------------------
  0            /usr/bin/g++       20        auto mode
* 1            /usr/bin/clang++   10        manual mode
  2            /usr/bin/g++       20        manual mode

Press enter to keep the current choice[*], or type selection number:


About fortran and objc we should use: /usr/bin/f90 and /usr/bin/objcc.sss

I moved my compiler-related changes to dpkg so that all tools use them. So now, we have:
wanna_build.patch - Fixes a bug in a script in wanna-build that is related to importing databases.
trigger.local - I use this to import local repositories to the wanna-build database. It's not necessary for wanna-build but can be useful to some people in a development process.
reprepro.patch - Fixes a bug in the manual page of reprepro.
sbuild.patch -  Fixes a bug in sbuild and work-arounds the problem that some sbuild scripts are called without reading the configuration file of sbuild.
dpkg.patch - The main patch with a lot of changes related to compiler support for building.

I have made lots of tests with them. I also have some documentation.

Next I'm going to look for potential problems and fix them. When I'm ready with my changes I'll contact the wanna-build team to connect the project with the Debian infrastructure.


More information about the Soc-coordination mailing list