The mesa project build is failing with “make[5]: *** No rule to make target `brw_cs.cpp’, needed by `brw_cs.lo’. Stop.”
Looking at the change logs, this seems like it was caused by Commit dc70c86b9b485cb5006a55cc2efd1f154dbfd469 “i965: Move compute shader code around” – where brw_cs.cpp turned into brw_cs.c
Build #189 introduces a new error “make[3]: *** No rule to make target `nir/nir_lower_samplers.cpp’, needed by `nir/nir_lower_samplers.lo’. Stop.”, caused by Commit de7ffdb38343b7f9292184ca827987de9852c80c “nir: rename nir_lower_samplers.c{pp,}”, which again turned a file from .cpp to .c
Checking the project configuration, it is also missing a clean step, which is exactly the kind of thing that fixes this sort of problem.
Fixed in build #205
Neil Hopcroft
A digital misfit
New project: SymPy
Following some warnings in the oftests build, I have added SymPy to the CI build. This is a standard python setup.py build.
Running this build gives
Processing dependencies for sympy==0.7.7.dev0
Searching for mpmath>=0.19
Reading https://pypi.python.org/simple/mpmath/
/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py:2512: PEP440Warning: ‘mpmath (0.4.src)’ is being parsed as a legacy, non PEP 440, version. You may find odd behavior and sort order. In particular it will be sorted as less than 0.0. It is recommend to migrate to PEP 440 compatible versions.
PEP440Warning,
…but then goes on to install mpmath-0.19-py2.7.egg.
Rebuilding it doesn’t give the same warnings, so it has resolved this dependency problem.
oftests hanging
I have set the Octave Forge tests to run every week, since the complete run of all tests should take nearly a day. It has recently been hanging, though, with an error about closing an IPC pipe:
Running some tests that reset the IPC and produce output
Resetting the octsympy communication mechanism
Closing the Python pipe…
Build was aborted
Earlier in the log there is a message
OctSymPy: Communication established. SymPy v0.7.6.
skipping: char(x) of assumptions suboptimal in <= 0.7.6
So it is worth updating to the latest version of SymPy anyway, and, if we’re lucky, that will fix the IPC problem too.
Build break – librsvg #147
The librsvg build reports:
/usr/local/lib/libpangoft2-1.0.so: undefined reference to `hb_ft_face_create’
/usr/local/lib/libpangoft2-1.0.so: undefined reference to `hb_ft_face_create_cached’
collect2: error: ld returned 1 exit status
This appears to be the result of a pango build problem.
Fixed in build #149.
Build break – pango #82
Pango build #82 fails with
./.libs/libpangoft2-1.0.so: undefined reference to `hb_ft_face_create’
./.libs/libpangoft2-1.0.so: undefined reference to `hb_ft_face_create_cached’
collect2: error: ld returned 1 exit status
There are no changes to pango itself in this build, so it is caused by changes to harfbuzz in build #28.
Looking at the changelog there, I see that Commit 2a9627c5641cd000e2adff0e42a0dc687b53ec70 includes a comment “Hope that doesn’t break too much client code.”, which is a somewhat suspicious. Although looking at the code itself, I don’t see any actual changes to the missing functions. Looking more closely at the configure logs, it seems that harfbuzz has lost its freetype dependency. The config.log in harfbuzz shows a number of missing pkg_config packages. Updating the PKG_CONFIG_PATH for the configure step fixes this, and, in turn, the pango build.
Fixed in build #85.
Build break – freetype #18
The freetype project build #18 is giving “libtool: link: require no space between `-L’ and `-lpng12′”, -L is intended to specify a path but no path is filled in there, thus it thinks -lpng12 is the path rather than a further option. Looking at the configure stage of the build shows:
Package libpng was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng.pc’
to the PKG_CONFIG_PATH environment variable
No package ‘libpng’ found
Which would give an explanation for the missing path. Specifying PKG_CONFIG_PATH for configure resolves this problem.
Fixed in build #19.
Platform updates causing build errors
Recently there was a significant number of package updates following a kernel update for the AWS instance I’m using. This has caused a number of build errors, which I think are the result of permissions reverting back to default rather than those I’ve changed to allow the build process to install files too – of course this isn’t the right solution, I should put the build user into a group allowed to make those changes by default, but that would require a bit more thinking about permissions than I can bring to bear at the moment. In the meantime, here are the projects affected by this problem:
- alabaster
- ffc
- fiat
- instant
- snowball
- sphinx_rtd_theme
- ufl
I have updated the site-packages permissions and rebuilt all of these packages, which has resolved all of these problems.
Dabbling with github and build automation
Github provides an API to search for repositories – this can be used directly from wget. As an experiment I have set up a simple script that gets the 30 most recently updated projects on github, clones them to a local directory, examines the code received, classifies it by build mechanism and, for some mechanisms, attempts to build it.
Here are the build mechanisms I have found:
- Python setup.py
- Dockerfile
- bootstrap.sh
- configure
- Makefile
- Vagrantfile
- build.gradle
- Gruntfile.js
- gulpfile.js
- package.json
- composer.json
- custom script based on project name
- Cartfile
- Rakefile
There are, I’m sure, more active build mechanisms and I will add those when I encounter them. From my experiments so far the above list covers about 90% of the currently active projects. Notably missing from the list are some of the Java build systems, like ant and maven, which suggests there might be other places for projects using those to live.
Adding Osmosis build
To get the event finder build back up to date I need to bring the version of Osmosis it uses up to the latest version. To do this I have added an Osmosis project to the Jenkins CI server. This is a Gradle build publishing to an Artifactory server, requiring installation of the Artifactory plugin to Jenkins.
An initial attempt to make this build gives me this error:
Execution failed for task ‘:artifactoryPublish’.
File ‘/usr/share/tomcat7/.jenkins/workspace/osmosis/osmosis-apidb/build/libs/osmosis-apidb-0.44.1-2-ge9b3ea5-SNAPSHOT.jar.asc’ does not exists, and need to be published!
This is a signature file, and is probably missing because task “:osmosis-apidb:signArchives SKIPPED”, as are all the other sign tasks – I haven’t configured the Gradle signing plugin yet. After a bit of messing around finding a version of gpg that wouldn’t complain when it came to entering the passphrase (cygwin to the rescue), installing and configuring the keys makes the build complete and publish the build result to Artifactory.
Setting up freetype
Harfbuzz needs the latest version of Freetype – I’ve added this to the CI build. This is again a standard ./autogen.sh ./configure make make install build.
Upgrading to the latest freetype fixes the harfbuzz build but breaks the octave build – fontconfig is still using the original freetype installed by yum, in /usr/ rather than the newly built one in /usr/local. Rebuilding fontconfig resolves this problem but causes the fltk build to fail. Setting fltk to look for the fontconfig.pc file in /usr/local/lib/pkgconfig resolves this.