Compiling with Jitter in sub-package mode when another version is installed

[Luca Saiu]

Hello.

Some friend, I think Darshit Shah, reported a problem I had already
encountered in my private tests: compiling Jitter in sub-package mode
when another version is installed may fail because of incompatibilities
between different version of the headers.

Incidentally I may have the same problem with Jitter's own examples; but
that will not be visible to others, and I can work around the issue even
in a very ad-hoc way.  Poke users will be affected more seriously.

This preliminary change, not heavily tested yet, should solve the issue,
but I am not happy about it and would like to discuss it with Darshit,
José and the other Poke people:

http://ageinghacker.net/git/cgit.cgi/jitter/commit/?h=fix-subpackage-builds-with-installed-headers&id=a05e27e094db4a1231c8793323153ae2ad3fe165

In this preliminary solution I am defining a new substitution,
JITTER_CPPFLAGS_ALWAYS, which is meant to be *always* prepended to the
CPP flags for every target built with Jitter headers so that the
sub-package directories have priority.  The revised definition of
AC_JITTER_SUBPACKAGE also changes AM_CPPFLAGS to include the value of
JITTER_CPPFLAGS_ALWAYS, so that in most "easy" cases the user will not
need to do anything -- notice that a CPPFLAGS variable defined by the
user does not cancel AM_CPPFLAGS but just adds more flags *to the right*
after AM_CPPFLAGS's expansion, which is exactly what we want.

Non-easy cases exist, however.  From the Automake manual:

     ‘AM_CPPFLAGS’ is ignored in preference to a per-executable (or
     per-library) ‘_CPPFLAGS’ variable if it is defined.

I use per-target flags a lot (compiling the same sources multiple times
with different flags is one of the cases where Automake abstractions
shine), and I see that Poke does it as well.

In such cases the user should remember to manually add
$(JITTER_CPPFLAGS_ALWAYS) to target_CPPFLAGS for every target, or risk
subtle failures on some configurations.

This is too fragile.


I am considering a different solution: *every* source file using a
Jitter header must be pre-processed with JITTER_CPPFLAGS or some
dispatch-specific version of it.  The new definitions of these
substitutions will include -I options in sub-package mode, plus (always)
the definition of a CPP macro which will serve the only purpose of
preventing a failure when defined.

Right now JITTER_CPPFLAGS, along with JITTER_CFLAGS, is only required to
compile generated VM files.  Other files, less critical to compile, may
still use some Jitter headers -- but those headers risk being the wrong
version, from a system directory.

Therefore the new jitter/jitter.h , be it installed or not, would
contain a CPP conditional such as:

#ifndef JITTER_CPPFLAGS_USED
# error "You must pre-process with JITTER_CPPFLAGS: see the manual"
#endif

This would force the user to pre-process with the correct flags which
come from AC_JITTER, AC_JITTER_SUBPACKAGE or, for non-Autotools
projects, directly from jitter-config ; only a user trying really hard
to shoot herself in the foot will pass the required flags manually and
run into problems.

JITTER_CPPFLAGS, differently from JITTER_CFLAGS, has no impact on
performance and is safe to use for every source file in a project even
in cases where Jitter is not really required.  I will also rename the
main config.h in the Jitter build directory to prevent collisions; every
other header file in Jitter already has a name starting with "jitter-".


What do you think of this proposed change?  I would like the build
process to be as robust as possible, while at the same time uniform in
behavior across an installed Jitter and sub-package mode.

I am interested in feedback.

Regards,

-- 
Luca Saiu
* My personal web site:  http://ageinghacker.net
* GNU epsilon:           http://www.gnu.org/software/epsilon
* Jitter:                http://ageinghacker.net/projects/jitter

I support everyone's freedom of mocking any opinion or belief, no
matter how deeply held, with open disrespect and the same unrelented
enthusiasm of a toddler who has just learned the word "poo".

signature.asc
Description: PGP signature