headers
Stephen Leake | 1 Aug 01:45
Favicon

Re: dvc-site.el considered harmful

Thien-Thi Nguyen <ttn <at> gnuvola.org> writes:

> I'd like to simply delete dvc-site.el and related support code.

Works for me. I expect dvc to find executables in PATH; if it doesn't,
I fix PATH, not dvc variables.

> The idea is that installed-DVC users can use the standard
> customization and/or ~/.emacs munging to effect the runtime tweaks,
> anyway, so what is the point of dvc-site.el? WDYT? What's a good way
> to replace, for example:
>
> | (dvc-first-set
> |    dvc-site-arch-branch
> |  (if (executable-find
> |       baz-executable)
> |      'baz
> |    'tla))

This is a major kludge anyway; there must be a better way to decide
between baz and tla?

--
-- Stephe
Permalink | Reply | 0 comments |
headers
Stephen Leake | 1 Aug 01:45
Favicon

Re: dvc-site.el considered harmful

Thien-Thi Nguyen <ttn <at> gnuvola.org> writes:

> I'd like to simply delete dvc-site.el and related support code.

Works for me. I expect dvc to find executables in PATH; if it doesn't,
I fix PATH, not dvc variables.

> The idea is that installed-DVC users can use the standard
> customization and/or ~/.emacs munging to effect the runtime tweaks,
> anyway, so what is the point of dvc-site.el? WDYT? What's a good way
> to replace, for example:
>
> | (dvc-first-set
> |    dvc-site-arch-branch
> |  (if (executable-find
> |       baz-executable)
> |      'baz
> |    'tla))

This is a major kludge anyway; there must be a better way to decide
between baz and tla?

--
-- Stephe
Permalink | Reply | 9 comments |
headers
Stephen Leake | 1 Aug 10:15
Favicon

Re: ttn-477-config-1 available

Thien-Thi Nguyen <ttn <at> gnuvola.org> writes:

> Summary of changes:
> <snip>
>
> I'll wait a few days before starting on -config-2, which depends on what
> people think of deleting dvc-site.el.  Notable for DVC hackers will be the
> blurb in docs/HACKING (Programs for maintainers).

This gives me some build errors:

make -r 
cd lisp; make
make[1]: Entering directory `/Gnu/dvc/lisp'
srcdir=. otherdirs="" emacs -batch -q --no-site-file -l ./dvc-build.el -f dvc-build-autoloads .
Env var `otherdirs' not set

Since the default is for 'otherdirs' to be empty, this can be fixed by
patching dvc-build.el:

(defvar otherdirs (or (getenv "otherdirs")
                      ""))

That lets the first build complete. But then if I rerun 'make' (just
to be sure), I get:

make -r 
cd lisp; make
make[1]: Entering directory `/Gnu/dvc/lisp'
srcdir=. otherdirs="" emacs -batch -q --no-site-file -l ./dvc-build.el -f dvc-build-autoloads .
(Continue reading)

Permalink | Reply | 6 comments |
headers
Thien-Thi Nguyen | 1 Aug 12:07
Favicon

Re: ttn-477-config-1 available

() Stephen Leake <stephen_leake <at> stephe-leake.org>
() Fri, 01 Aug 2008 04:15:36 -0400

   This gives me some build errors:

Thanks for the bug reports.

   make -r 
   cd lisp; make
   make[1]: Entering directory `/Gnu/dvc/lisp'
   srcdir=. otherdirs="" emacs -batch -q --no-site-file -l ./dvc-build.el -f dvc-build-autoloads .
   Env var `otherdirs' not set

   Since the default is for 'otherdirs' to be empty, this can be fixed by
   patching dvc-build.el:

Interesting.  On my system, i see:

(let ((process-environment (cons "unlikely=" process-environment)))
  (getenv "unlikely"))
=>""

I suppose you see =>nil (can you confirm?).

   (defvar otherdirs (or (getenv "otherdirs")
                         ""))

Yeah, that was the original construct.  I thought more strictness would help,
but that depends on the above behavior (i.e., =>"").  I have changed the code
as you suggest (patch attached).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thien-Thi Nguyen | 1 Aug 16:56
Favicon

Re: ttn-477-config-1 available

() Stephen Leake <stephen_leake <at> stephe-leake.org>
() Fri, 01 Aug 2008 04:15:36 -0400

   make -r 
   cd lisp; make
   make[1]: Entering directory `/Gnu/dvc/lisp'
   srcdir=. otherdirs="" emacs -batch -q --no-site-file -l ./dvc-build.el -f dvc-build-autoloads .
   Merging cus-load.el into dvc-autoloads.el (c:\Gnu\dvc\lisp/)...
   Opening input file: no such file or directory, c:/Gnu/dvc/lisp/cus-load.el

   cus-load.el is generated by the build process, but then it is deleted.
   Here are the relevant messages from the build process:

   Generating cus-load.el...
   Wrote c:/Gnu/dvc/lisp/cus-load.el
   Generating cus-load.el...done
   ...
   Merging cus-load.el into dvc-autoloads.el (c:/Gnu/dvc/lisp/)...

   In dvc-build.el, dvc-build-autoloads does:

           (message "Merging %s into %s (%s)..."
                    (file-name-nondirectory --custom-autoloads-filename)
                    (file-name-nondirectory --autoloads-filename)
                    default-directory)
           (with-temp-file --autoloads-filename
             (insert-file-contents --custom-autoloads-filename)
             (delete-file --custom-autoloads-filename)

   I've commented out the 'delete-file' for now.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stefan Reichör | 1 Aug 21:59
Picon

Offline for a week

Hi!

I just wanted to inform you that I am offline for a week.

I will be with my family in a nice kinder-hotel in austria
(http://www.appelhof.at)

Stefan.
Permalink | Reply | 0 comments |
headers
Stephen Leake | 2 Aug 14:22
Favicon

Re: ttn-477-config-1 available

Thien-Thi Nguyen <ttn <at> gnuvola.org> writes:

>    I've commented out the 'delete-file' for now.
>
> Hmm, that fragment is evaluated after `custom-make-dependencies' (which
> is the function that writes cus-load.el) is called, so in theory
> cus-load.el should exist in the current directory.  

When I re-run make, it says:

make -r 
cd lisp; make
make[1]: Entering directory `/Gnu/dvc/lisp'
srcdir=. otherdirs="" emacs -batch -q --no-site-file -l ./dvc-build.el -f dvc-build-autoloads .
Merging cus-load.el into dvc-autoloads.el (c:\Gnu\dvc\lisp/)...
Opening input file: no such file or directory, c:/Gnu/dvc/lisp/cus-load.el

So custom-make-dependencies is not run in this case.

> Perhaps some defunct .el{c} files still lying might be confusing
> `missing-or-old-elc'. Can you reproduce the problem with a clean
> checkout or after a "make clean" (and with the `otherdirs' patch
> applied)?

Yes, same problem after clean checkout, autoreconf, configure, make,
make.

>    Now when I run 'make', it always regenerates the autoloads. I guess
>    that's why cus-loads is deleted, but something needs to change.
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thien-Thi Nguyen | 2 Aug 15:18
Favicon

Re: ttn-477-config-1 available

() Stephen Leake <stephen_leake <at> stephe-leake.org>
() Sat, 02 Aug 2008 08:22:51 -0400

   So custom-make-dependencies is not run in this case.

OK.

   > [ttn in-the-dark guess]

   Yes, same problem after clean checkout, autoreconf, configure, make,
   make.

OK.

   missing-or-old-elc returns ("dvc-autoloads.el") in this case.

   [Aside: which I discovered by convincing dvc-build.el to let me run
    interactively. It's really a pain trying to debug this stuff!]

Yeah, i know how you feel.  On the one hand, interactivity introduces
personal environment (~/.emacs et al) problems, so you want to enforce
non-interactive operation/testing, but on the other hand, visibility for
non-interactive debugging is really poor.  Here's a small function that
you might find useful when forced to do "printf-debugging":

(defun pk (&rest args)
  (apply 'message (car args) (cdr args))
  (car (last args)))

This is styled after Guile's `pk' and supported by pk-unpk.el (attached).
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thien-Thi Nguyen | 2 Aug 17:49
Favicon

Re: ttn-477-config-1 available

() Thien-Thi Nguyen <ttn <at> gnuvola.org>
() Sat, 02 Aug 2008 15:18:35 +0200

   Good catch!  Since dvc-autoloads.el is written in `default-directory',
   anyway, the `expand-file-name' is indeed superfluous.

Oops, looks like i spoke too soon.  Here's a log fragment:

 |-*- mode: compilation; default-directory: "~/build/MISC/dvc.b/lisp/" -*-
 |Compilation started at Sat Aug  2 17:42:02
 |
 |cd ~/build/MISC/dvc.b/lisp ; touch /home/ttn/build/MISC/dvc/lisp/xhg-core.el ; make
 |srcdir=../../dvc/lisp otherdirs="/x /y /z" emacs -batch -q --no-site-file -l
../../dvc/lisp/dvc-build.el -f dvc-build-autoloads ../../dvc/lisp
 |Loading cus-dep...
 |Directory ../../dvc/lisp
 |Generating cus-load.el...
 |Wrote /home/ttn/build/MISC/dvc.b/lisp/cus-load.el
 |Generating cus-load.el...done
 |Generating autoloads for ../../../MISC/dvc/lisp/xhg-core.el...
 |Generating autoloads for ../../../MISC/dvc/lisp/xhg-core.el...done
 |Saving file /home/ttn/build/GNU/emacs/lisp/dvc-autoloads.el...
||Wrote /home/ttn/build/GNU/emacs/lisp/dvc-autoloads.el
 |Merging cus-load.el into dvc-autoloads.el (/home/ttn/build/MISC/dvc.b/lisp/)...
 |Compiling dvc-autoloads.el...
 |Wrote /home/ttn/build/MISC/dvc.b/lisp/dvc-autoloads.elc

Note the emphasized (double-pipe) line: Apparently, dvc-autoloads.el
is NOT actually being written in default directory.  Luckily, the following
small patch, which reintroduces `expand-file-name' at file-generation time,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thien-Thi Nguyen | 3 Aug 12:14
Favicon

ttn-477-makefiles-3 available

Note that on <http://www.gnuvola.org/wip/> there is a "(plus, ...)"
section that can be safely ignored.  This is because -makefiles-3 was
based on an older revision; what you see is the -config-1 changes.
Regardless, to create a patch, use the command:

$ git diff bzr-revno-477 ttn-477-makefiles-3

Summary of changes:
  Fix bug: Relax env var `otherdirs' check for "make all".
  Fix bug: For lisp/ "make autoloads", expand autoload filename later.
  Require explicit `bye-bye' for lisp/dvc-build.el functions.
  Incorporate lisp/ "make autoloads" into "make all" (and "make all-verbose").

The last change reduces the number of $(ebatch) calls to one, which is as
low as you can get, and includes other (dvc-build.el internal) changes to
do things only once instead of repeatedly.  (End result: faster "make".)

I am still perplexed by the quantity of "Generating autoloads" messages,
so perhaps there will be a -makefiles-4 concentrating on that weirdness,
especially since...

There's no rush for -config-2 as people are vacationing.  I'll ping the
list again towards end of month; we can decide the fate of dvc-site.el et
al then.

thi
Permalink | Reply | 0 comments |

Gmane