Samuel Chase wrote:
> Should a 'clang-build' branch be created, and new commits pulled
> from trunk, so that it will be easy to make sure whether trunk builds?
Feel free to do so if you think it helps to get more clang build tests done on various platforms (and with different versions/flavors of clang), along with tests with various GCC versions (to test for possible regressions introduced for other compilers).
Currently, I build trunk with clang [1] several times a week (using local branches of trunk with the changes we have so far applied), and can report regressions which cause it to fail to compile (runtime tests are only minimal ATM). This works ok for me as long as there are as few changes as currently required. I also have the same patches applied to my regular branches which compile with llvm-gcc-4.2 (to test for unintentional side-effects).
OTOH having a branch pushed to launchpad, which is kept up-to-date with regular merges from trunk, would make it easy to create up-to-date diffs anytime…
Right now, I'm more worried about getting 'configure.ac' ready for clang, proper recommendations for CFLAGS/CXXFLAGS [2] (which probably also could be addressed in configure.ac), and about the lack of OpenMP support in clang (even if OpenMP support with llvm-gcc.4.2 is not very stable (bug #984836), the difference is still quite noticeable, even with only a few blurs in a drawing).
-----
[1] a somewhat dated version from Apple (see comment #9 for details)
[2] without additional flags (e.g. --Wno-mismatched-tags), I got a huge build log file (3.4MB):
Chillida:mp-quartz-clang su_v$ grep 'Wmismatched-tags' ../../_log/2013-02-15-mp-quartz-clang-12129.txt | wc -l
9456
Samuel Chase wrote:
> Should a 'clang-build' branch be created, and new commits pulled
> from trunk, so that it will be easy to make sure whether trunk builds?
Feel free to do so if you think it helps to get more clang build tests done on various platforms (and with different versions/flavors of clang), along with tests with various GCC versions (to test for possible regressions introduced for other compilers).
Currently, I build trunk with clang [1] several times a week (using local branches of trunk with the changes we have so far applied), and can report regressions which cause it to fail to compile (runtime tests are only minimal ATM). This works ok for me as long as there are as few changes as currently required. I also have the same patches applied to my regular branches which compile with llvm-gcc-4.2 (to test for unintentional side-effects).
OTOH having a branch pushed to launchpad, which is kept up-to-date with regular merges from trunk, would make it easy to create up-to-date diffs anytime…
Right now, I'm more worried about getting 'configure.ac' ready for clang, proper recommendations for CFLAGS/CXXFLAGS [2] (which probably also could be addressed in configure.ac), and about the lack of OpenMP support in clang (even if OpenMP support with llvm-gcc.4.2 is not very stable (bug #984836), the difference is still quite noticeable, even with only a few blurs in a drawing).
----- d-tags) , I got a huge build log file (3.4MB): mp-quartz- clang su_v$ grep 'Wmismatched-tags' ../../_ log/2013- 02-15-mp- quartz- clang-12129. txt | wc -l
[1] a somewhat dated version from Apple (see comment #9 for details)
[2] without additional flags (e.g. --Wno-mismatche
Chillida:
9456