Enable Travis CI v2

[b4n]

Would replace #172, which see also.

This is a new shot at enabling Travis CI on Geany-Plugins. This time, it uses the new-style infrastructure which enables caching and is quite faster to start up.

• Pros:
  • Faster to start up
  • Has cache support
    • We can build Geany and cache the result, meaning we can rebuild it only when it has changed. This makes me think its better than using nightly _.deb_s, as we have the real latest version in all cases, and zero OS package compatibility issue.
    • ccache support, meaning faster rebuilds
• Cons:
  • No sudo, which means:

    • We need their approval for new packages. We currently miss:

      • libvte-dev (for several plugins, incl. Debugger, Scope and MultiTerm)
      • libwnck-dev (for DevHelp)
      • libgtkspell-dev (for GeanyVC's spellchecking support on GTK2)
      • libgtkspell-3-dev (for GeanyVC's spellchecking support on GTK3)
      • python-gtk2-dev (for GeanyPy)

      this can however probably be addressed by using they approval procedure for those packages. If we chose this version, I'll submit the requests there.

    • No 3rd party repositories (e.g. we have to build Geany there too). This should not be a real problem with the caching, in my tests I saw it wasting about 7s when the cache is available, and something like 2 minutes without cache.

IMO, the pros clearly beat the cons -- unless we really can't get the needed packages, but I'm confident we can.

---

Unrelated to whether we use the new infrastructure or the old one, we run on Ubuntu 12.04. This is good in the sense we test an old-ish system; but it's bad as in it doesn't have libpython-dev (for GeanyPy) nor libgit2-dev >= 0.21 (for GitChangeBar).

We could try and use their beta Ubuntu 14.04 builders, which allows sudo, and has cache. Sounds nice, but:

• It's quite a bit slower than their 12.04 "new" infrastructure (build takes minutes to start, not seconds: not sure about speed after startup)
• Ubuntu 14.04's libgit2-dev is too old (0.19) for GitChangeBar, so we "only" gain GeanyPy
• Newer system, while good, also means less backward compatibility checks.

I didn't pursue it for the moment because of these which make me think we should at least wait for their setup to get faster seeing the limited benefits.

---

Setting up this, I found 4 blocker issues, including 3 actual bugs:

• Skip auto-generated C sources from translation setup #392: make check breaks if MultiTerm is disabled. So actually missing libvte-dev was useful :)
• spellcheck: Use <> to include Geany headers #393: Ubuntu 12.04's cppcheck is stupid
• lineoperations: Fix a memory leak found by cppcheck #391: Ubuntu 12.04's cppcheck is clever
• debugger: Don't rely on an Automake test driver implementation detail #395: Incorrect build system assumption from a Debugger test script (won't be a problem until we have libvte though)

---

Enough chatter, whatcha guys thinkin'?

[b4n]

BTW, actual build links:

• https://travis-ci.org/b4n/geany-plugins/builds/114321338 this PR, failing because of the linked issues
• https://travis-ci.org/b4n/geany-plugins/builds/114315098 same setup, but with the fixes for the issues applied.

[codebrainz]

I don't have much preference other than it works and shows the status on PR within some time.

Maybe the old Python package was called python-dev?

[b4n]

@codebrainz Nice! that seem to work indeed. It won't work here still because it also requires python-gtk2-dev that isn't allowed (yet), but it was shown working in a sudo-enabled test, so that will work if the package gets approved.

[b4n]

• python-gtk2-dev: APT whitelist request for python-gtk2-dev travis-ci/apt-package-safelist#2680
• libgtkspell-3-dev: APT whitelist request for libgtkspell-3-dev travis-ci/apt-package-safelist#2679
• libgtkspell-dev: APT whitelist request for libgtkspell-dev travis-ci/apt-package-safelist#2678
• libvte-dev: APT whitelist request for libvte-dev travis-ci/apt-package-safelist#2675
• libvte-2.90-dev: APT whitelist request for libvte-2.90-dev travis-ci/apt-package-safelist#2263 (not sure we need this one here)
• libwnck-dev: APT whitelist request for libwnck-dev travis-ci/apt-package-safelist#2677

[b4n]

#395 is more than likely to also affect this version of the TravisCI setup.

[b4n]

Added a commit building and caching libgit2 0.21.5 as it's just not available in Ubuntu 12.04 or even 14.04. It's small, it builds quickly (less than 10s apparently well, I don't know, might have included ccache speedup), and it'll be cached basically forever (until dependency bump or cache expiration, if such a thing exists) once built.
With this, GitChangeBar builds fine.

[frlan]

Do we really want to build with j2? On Travis I don't see much we are winning but error output might be harder to read.

[b4n]

Travis container-based build machines advertize 2 cores in the docs, and legacy VM ones 1.5. So actually for speed we could even go to 3 parallel jobs (or more) to account for time wasted in non-CPU-bound operations (file reads, etc.).

error output might be harder to read.

How so? Any sane Make implementation has output synchronization, and GNU Make's default is to group target output together, so I don't see the issue? But even if target-grouping is not enough in your opinion, we could choose recursive grouping (--output-sync=recursive).

[frlan]

OK. I just dropped -j out of my mind years ago as it didn't work. If its working by now, I'm fine ;)

[b4n]

Rebased on master to get the required fixes, and I took the opportunity to squash the 2 GeanyPy-related commits, and fixing a comment.

PS: travis is running this PR ;)