(Please see <http://www.gnuvola.org/wip/> for more info.)

This wraps up makefile-centric config/build munging, modulo bugfixes.
Most changes should be uncontroversial, though i'd like to point out
a bugfix that may prove unpopular (see below for commit log entry).
Feedback welcome.

Next series will be -config-N, which will focus on configure.ac.
The primary goal of the series will be to remove DVC-maintainer
stuff (such as makeinfo(1) detection) from the configuration
process, so that DVC-end-user doesn't have to deal w/ it.
For -config-1, i don't expect any changes outside configure.ac
itself and the collaborating Makefile.in files.

For -config-2, however, i envision things like baz-vs-tla checks
to be moved out of configure-time completely (to run-time), which
would likely involve lisp/*.el munging.  I will be asking for
guidance then, so don't be surprised when Janitorial Ignorance
rears its head!

In any case, if anyone has any configuration hints / pointers /
wish-list items, now is a good time to make them known.

thi

_________________________________________________________
commit 17e23cacdcf4da83a795e4a19638dc180838d742
Date: Mon Jul 28 11:06:08 2008 +0200

 Consolidate build functionality into dvc-build.el.
 
 In the process of integrating package-maint.el, we also fix a small
 bug.  Consider the case where bot.el requires mid.el requires top.el.
 That is, bot.el has (require 'mid);
     and  mid.el has (require 'top).
 Now we touch top.el.  Previously, this would cause recompilation of
 top.el and mid.el, only, and not bot.el.  That is, the files to be
 (re-)compiled consisted of the root set (top.el) and their immediate
 dependents (mid.el).
 
 This is perfectly sufficient except in the case where mid.el defines
 macros whose definitions change due to changes in top.el, and whose
 definitions are used by bot.el.  Do such cases exist?  We don't know;
 we don't do anything to identify them.  Thus, IF they do exist, not
 compiling bot.el MAY introduce skew problems.
 
 Two resolutions come to mind to achieve assurance that skew problems
 cannot exist: a/ identify this case and recompile bot.el if needed;
 b/ recompile bot.el unconditionally.
 
 We choose b/ because a/ is hard.  Practically, this means we compute
 the complete fan-out of the root set and in most cases (where there
 is no macro dependency as described above), recompile more files than
 strictly necessary.  This is the cost of erring on the safe side.
 
 * lisp/dvc-build.el: Signal error if loaded interactively.
 Integrate contrib/package-maint.el; no longer require `package-maint'.
 Push nil on `load-path' last.
 When adding `otherdirs', remove null strings from `split-string' rv.
 Combine top-level conditional of Emacs-specific byte-compiler fixups.
 (srcdir, otherdirs): Signal error if env var not set.
 (builddir, contribdir, loaddir): Delete vars.
 (package-maint-pkg, no-compile-files): Delete vars.
 (zonk-file, f-set-difference, f-intersection, srcdir/): New funcs.
 (--warnings): Rename from `package-maint-compile-warnings'.
 (--autoloads-filename): Rename from `package-maint-load-file'.
 (--custom-autoloads-filename): Rename from `package-maint-cus-load-file'.
 (--to-compile): Rename from `package-maint-files';
 compute value once, at dvc-build.el-load time.
 (byte-compile-dest-file): Rewrite.
 (missing-or-old-elc): Rename from `package-maint-changed-source-p';
 use `remove-if-not'.
 (dvc-build-compile): Rewrite.
 (dvc-build-autoloads): Rewrite.
 
 * lisp/contrib/package-maint.el: Delete file.

_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev

Reply via email to