libosmocore build failure cascade

As you may have noticed, Vadim's new coding generation code caused numerous builds to fall on their faces. The reasons why what failed are not so trivial, so let me explain. In short, - we place generated artifacts in the $builddir, which ensures clean builds after removing the $builddir. Because we do that, we sometimes need to also -I$(builddir)/include for builds where $(builddir) != $(srcdir). - for generated files, it is important to have proper make dependencies to rebuild them when the sources for generation change. - in build jobs, it is important to wipe the workspace clean, particularly in the presence of generated source files that don't have proper make dependencies. What I saw today: (1) libosmocore master build failed https://jenkins.osmocom.org/jenkins/job/libosmocore/866/ (2) gerrit libosmocore patch checking build *succeeded* for the failing patch (3) libosmocore build actually first *succeeded* even in clean src dir (4) libosmocore build from different dir on clean *system* failed (5) new generated files ended up in $srcdir (6) debian build complained about files present but not installed My first guess was: the gerrit job fails to clean the workspace and hence works because old headers remain; the master build fails because it properly cleans up the workspace and checks building from another dir. Not at all :) (1) In fact the libosmocore *master* build failed because it did not properly clean up the workspace. The old headers remained, but lacked some symbols that were now undefined during compilation. --> added rm -rf *; git checkout . to the libosmocore master build. --> https://gerrit.osmocom.org/2002 ensures regeneration by changed gen code (If there are more deps that could be added there, please go ahead!) (2) The gerrit libosmocore patch succeeded because it properly cleans up the workspace, and does not check building from a separate dir. So it regenerated all headers in $srcdir, which is fine when also building in $srcdir. --> https://gerrit.osmocom.org/1998 tests separate dir in jenkins.sh (3) If I still have libosmocore headers in e.g. /usr/local/include, the build will take those when missing in the src tree and may actually succeed. So I had to go and rm -rf /usr/local/include/osmocom to reproduce the failure. :/ (4) Build from different dir fails because coding/gsm0503_interleaving.c #includes a header that is generated in $builddir (already before this patch), but coding/Makefile.am did not -I$(builddir)/include. --> https://gerrit.osmocom.org/2003 adds -I builddir in coding/ (5) While generating files in $srcdir does not necessarily break builds, it's better to write to $builddir instead -- removing $builddir then clears the build state completely. Fixed up to generate to $builddir, also in: --> https://gerrit.osmocom.org/1996 generates gsm0503 to builddir (6) *All* files part of 'make install' need to be mentioned in debian/*, either as files to be ignored or files to be installed. Max fixed it in: --> https://gerrit.osmocom.org/1989 --> do we want to add deb build checking to the gerrit job? I spent some time on cleaning failures from that patch, but then spent some extra time to help us not run into these problems again... Thanks for being aware of these issues. ~N -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte