Building emacs with and without X -- packaging question.

Building emacs with and without X -- packaging question.

[Rob Browning]

I've had a *long* standing request wrt the Debian packages that I
provide a non-X version that doesn't depend on any of the X packages.
I finally sat down to accomodate this the other day and managed to
reworked things to produce emacs21, emacs21-nox, and emacs21-el
packages, emacs21-nox being the new one, built with --with-x=no.  To
be completely safe, the way I did this was to configure and build
Emacs twice, once with --with-x=no, and once without.  Then I took the
two seprarate install trees and used those to create the two emacs21
and emacs21-nox binary packages, only one of which you can have
installed at a time.

The problem with this approach is that it requires two full Emacs
builds (and since we use bootstrap, it's a long build), and it roughly
doubles the storage required for the resulting packages.  James
pointed out to me that now that Debian supports over 10 architectures,
some of which are very slow builders, this will consume a lot more
archive space and build time.

An alternate approach would be to still build Emacs twice, but put all
the bits that the two trees have in common into an emacs21-common
package.  Then the emacs21 and emacs21-nox packages might not need to
be much more than the actual application binary.  However this
wouldn't be safe if the files in the with and without-x install trees
are likely to be different in important ways (i.e. different sets of
files, binary incompatibilities in .elc files, etc.).

Another way it might not be safe is if add-on emacs packages, like
calc, psgml, etc. could detect whether they were being compiled by an
X or non-X Emacs and generate differing .elc files as a result.  (This
wouldn't be safe in the current Debian arrangement, if I was going to
try to allow emacs21 and emacs21-nox to be installed simultaneously,
but could be made so, if needed.)

Accordingly I wanted to check with you upstream and see if you
considered this a viable approach, or if you had a preferred
alternative.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Eli Zaretskii]

> From: Rob Browning <rlb@defaultvalue.org>
> Date: Fri, 31 May 2002 12:25:09 -0500
> 
> An alternate approach would be to still build Emacs twice, but put all
> the bits that the two trees have in common into an emacs21-common
> package.  Then the emacs21 and emacs21-nox packages might not need to
> be much more than the actual application binary.  However this
> wouldn't be safe if the files in the with and without-x install trees
> are likely to be different in important ways (i.e. different sets of
> files, binary incompatibilities in .elc files, etc.).

There should not be any such incompatibilities.  The .elc files could
be slightly different, but they should work at run time anyway.

> Another way it might not be safe is if add-on emacs packages, like
> calc, psgml, etc. could detect whether they were being compiled by an
> X or non-X Emacs and generate differing .elc files as a result.

I think this issue doesn't exist.

> Accordingly I wanted to check with you upstream and see if you
> considered this a viable approach

FWIW, I think you should indeed put all the *.el and *.elc files into
a common package.  If disk storage is a problem, you could have all
the X-specific *.el/*.elc files in a separate package, but I'd rather
think the savings will be minimal, since most Lisp files are not
specific to any display type.

Re: Building emacs with and without X -- packaging question.

[Alan Shutko]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> There should not be any such incompatibilities.  The .elc files could
> be slightly different, but they should work at run time anyway.

DOC is the traditional bugaboo, and the linux distributions who do
this have patches, iirc.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
If you drink, don't park.  Accidents make people.

Re: Building emacs with and without X -- packaging question.

[Alan Shutko]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> If you mean that DOC doesn't include all the doc strings it should,
> then it's a bug that should be fixed.

No, it's related to this section from etc/PROBLEMS:

    * Self documentation messages are garbled.

    This means that the file `etc/DOC-...' doesn't properly correspond
    with the Emacs executable.  Redumping Emacs and then installing the
    corresponding pair of files should fix the problem.

I'm afraid I don't know how this section works, just that if you
recompile Emacs without X but use the DOC from the X version, the
messages are garbled.  The RH patches I looked at way back when
referenced a DOC and a DOC-X11, depending on how it was compiled
(iirc).

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
My, how you've changed since I've changed.

Re: Building emacs with and without X -- packaging question.

[Eli Zaretskii]

> Date: Sat, 01 Jun 2002 12:42:20 -0400
> From: Alan Shutko <ats@acm.org>
> 
> I'm afraid I don't know how this section works, just that if you
> recompile Emacs without X but use the DOC from the X version, the
> messages are garbled.

That's a clear sign of a bug, IMHO.  src/Makefile.in is supposed to be
set up so that all versions of Emacs get the same functions
documented.  That's why ${docdir} is not architecture dependent.

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> That's a clear sign of a bug, IMHO.  src/Makefile.in is supposed to
> be set up so that all versions of Emacs get the same functions
> documented.  That's why ${docdir} is not architecture dependent.

OK, so from what everyone says, it sounds like only the binary is
supposed to differ, and so I should be able to just package that
separately.

What about the above comment, though?  If the DOC issue is a bug, I'd
be happy to see if I can fix it.  I'd rather spend the time on that
than on some less appropriate hack.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Alan Shutko]

Rob Browning <rlb@defaultvalue.org> writes:

> What about the above comment, though?  If the DOC issue is a bug, I'd
> be happy to see if I can fix it.  I'd rather spend the time on that
> than on some less appropriate hack.

The DOC files do differ between compiles.  If you ./configure and then
./configure --without-x, you'll see a .1 and a .2.  Emacs will
normally use those correctly.  (The files do differ... try diffing or
swapping them and trying them from Emacs... 

C-n runs the command next-line
   which is an interactive compiled Lisp function in `simple'.
(next-line ARG)

ion of the current buffer to be copied.

)  But if you did two separate clean builds, the build id in the
version would be the same and they would use the same file, and have
problems... I think it uses offsets or something.

I tried this with 21.2.90.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Even a hawk is an eagle among crows.

Re: Building emacs with and without X -- packaging question.

[Stefan Monnier]

> Rob Browning <rlb@defaultvalue.org> writes:
> 
> > What about the above comment, though?  If the DOC issue is a bug, I'd
> > be happy to see if I can fix it.  I'd rather spend the time on that
> > than on some less appropriate hack.
> 
> The DOC files do differ between compiles.  If you ./configure and then
> ./configure --without-x, you'll see a .1 and a .2.  Emacs will
> normally use those correctly.  (The files do differ... try diffing or

Please show us the diff, since any difference is a bug.
There've been reports of such bugs in the past and they're pretty easy
to fix.  I don't know of any outstanding such problem, but that's no
guarantee.


	Stefan

Re: Building emacs with and without X -- packaging question.

[Alan Shutko]

Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> Please show us the diff, since any difference is a bug.

Ok.  Turns out it's very small.

*** etc/DOC-21.2.90.1	Mon Jun 10 16:11:09 2002
--- etc/DOC-21.2.90.2	Mon Jun 10 16:15:01 2002
***************
*** 2507,2607 ****
  Note that if value is nil, a scalable font might still be used, if no
  other font of the appropriate family and registry is available.\x1fVface-ignored-fonts
  List of ignored fonts.
! Each element is a regular expression that matches names of fonts to ignore.\x1fFquery-fontset
! Return the name of a fontset that matches PATTERN.
! The value is nil if there is no matching fontset.
! PATTERN can contain `*' or `?' as a wildcard
! just as X font name matching algorithm allows.
! If REGEXPP is non-nil, PATTERN is a regular expression.
! 
! (query-fontset PATTERN &optional REGEXPP)\x1fFnew-fontset
! Create a new fontset NAME that contains font information in FONTLIST.
! FONTLIST is an alist of charsets vs corresponding font name patterns.
! 
! (new-fontset NAME FONTLIST)\x1fFset-fontset-font
! Modify fontset NAME to use FONTNAME for CHARACTER.
! 
! CHARACTER may be a cons; (FROM . TO), where FROM and TO are
! non-generic characters.  In that case, use FONTNAME
! for all characters in the range FROM and TO (inclusive).
! CHARACTER may be a charset.   In that case, use FONTNAME
! for all character in the charsets.
! 
! FONTNAME may be a cons; (FAMILY . REGISTRY), where FAMILY is a family
! name of a font, REGSITRY is a registry name of a font.
! 
! (set-fontset-font NAME CHARACTER FONTNAME &optional FRAME)\x1fFfont-info
! Return information about a font named NAME on frame FRAME.
! If FRAME is omitted or nil, use the selected frame.
! The returned value is a vector of OPENED-NAME, FULL-NAME, CHARSET, SIZE,
!   HEIGHT, BASELINE-OFFSET, RELATIVE-COMPOSE, and DEFAULT-ASCENT,
! where
!   OPENED-NAME is the name used for opening the font,
!   FULL-NAME is the full name of the font,
!   SIZE is the maximum bound width of the font,
!   HEIGHT is the height of the font,
!   BASELINE-OFFSET is the upward offset pixels from ASCII baseline,
!   RELATIVE-COMPOSE and DEFAULT-ASCENT are the numbers controlling
!     how to compose characters.
! If the named font is not yet loaded, return nil.
! 
! (font-info NAME &optional FRAME)\x1fFinternal-char-font
! For internal use only.
! 
! (internal-char-font POSITION)\x1fFfontset-info
! Return information about a fontset named NAME on frame FRAME.
! The value is a vector:
!   [ SIZE HEIGHT ((CHARSET-OR-RANGE FONT-SPEC OPENED ...) ...) ],
! where,
!   SIZE is the maximum bound width of ASCII font in the fontset,
!   HEIGHT is the maximum bound height of ASCII font in the fontset,
!   CHARSET-OR-RANGE is a charset, a character (may be a generic character)
!     or a cons of two characters specifying the range of characters.
!   FONT-SPEC is a fontname pattern string or a cons (FAMILY . REGISTRY),
!     where FAMILY is a `FAMILY' field of a XLFD font name,
!     REGISTRY is a `CHARSET_REGISTRY' field of a XLDF font name.
!     FAMILY may contain a `FOUNDARY' field at the head.
!     REGISTRY may contain a `CHARSET_ENCODING' field at the tail.
!   OPENEDs are names of fonts actually opened.
! If the ASCII font is not yet opened, SIZE and HEIGHT are 0.
! If FRAME is omitted, it defaults to the currently selected frame.
! 
! (fontset-info NAME &optional FRAME)\x1fFfontset-font
! Return a font name pattern for character CH in fontset NAME.
! If NAME is t, find a font name pattern in the default fontset.
! 
! (fontset-font NAME CH)\x1fFfontset-list
! Return a list of all defined fontset names.
! 
! (fontset-list)\x1fVfont-encoding-alist
! Alist of fontname patterns vs corresponding encoding info.
! Each element looks like (REGEXP . ENCODING-INFO),
!  where ENCODING-INFO is an alist of CHARSET vs ENCODING.
! ENCODING is one of the following integer values:
! 	0: code points 0x20..0x7F or 0x2020..0x7F7F are used,
! 	1: code points 0xA0..0xFF or 0xA0A0..0xFFFF are used,
! 	2: code points 0x20A0..0x7FFF are used,
! 	3: code points 0xA020..0xFF7F are used.\x1fVuse-default-ascent
! Char table of characters whose ascent values should be ignored.
! If an entry for a character is non-nil, the ascent value of the glyph
! is assumed to be what specified by _MULE_DEFAULT_ASCENT property of a font.
! 
! This affects how a composite character which contains
! such a character is displayed on screen.\x1fVignore-relative-composition
! Char table of characters which is not composed relatively.
! If an entry for a character is non-nil, a composition sequence
! which contains that character is displayed so that
! the glyph of that character is put without considering
! an ascent and descent value of a previous character.\x1fValternate-fontname-alist
! Alist of fontname vs list of the alternate fontnames.
! When a specified font name is not found, the corresponding
! alternate fontnames (if any) are tried instead.\x1fVfontset-alias-alist
! Alist of fontset names vs the aliases.\x1fVhighlight-wrong-size-font
! *This variable is obsolete.\x1fVclip-large-size-font
! *This variable is obsolete.\x1fVvertical-centering-font-regexp
! *Regexp matching font names that require vertical centering on display.
! When a character is displayed with such fonts, the character is displayed
! at the vertival center of lines.\x1fFinvocation-name
  Return the program name that was used to run Emacs.
  Any directory names are omitted.
  
--- 2507,2513 ----
  Note that if value is nil, a scalable font might still be used, if no
  other font of the appropriate family and registry is available.\x1fVface-ignored-fonts
  List of ignored fonts.
! Each element is a regular expression that matches names of fonts to ignore.\x1fFinvocation-name
  Return the program name that was used to run Emacs.
  Any directory names are omitted.
  


-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Everybody wants to go to heaven, but nobody wants to die.

Re: Building emacs with and without X -- packaging question.

[Eli Zaretskii]

On Mon, 10 Jun 2002, Alan Shutko wrote:

> Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> 
> > Please show us the diff, since any difference is a bug.
> 
> Ok.  Turns out it's very small.

Indeed.  It sounds like adding fontset.o to SOME_MACHINE_OBJECTS on 
src/Makefile.in should fix that.  Can you try?

I think we also saw similar problems with the Windows port, so perhaps 
someone who can build a Windows version could compare the DOC file with 
the Unix version, and see whether more files are missing from the 
respective lists in src/Makefile.in.

Re: Building emacs with and without X -- packaging question.

[Alan Shutko]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> Indeed.  It sounds like adding fontset.o to SOME_MACHINE_OBJECTS on 
> src/Makefile.in should fix that.  Can you try?

Yes, it fixed it.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Nice guys get sick.

Re: Building emacs with and without X -- packaging question.

[Juanma Barranquero]

On Tue, 11 Jun 2002 08:36:15 +0300 (IDT), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> I think we also saw similar problems with the Windows port, so perhaps 
> someone who can build a Windows version could compare the DOC file with 
> the Unix version, and see whether more files are missing from the 
> respective lists in src/Makefile.in.

I've bootstrapped HEAD on Windows and on a RedHat 7.2, I've extracted
the symbols from each (text between \x1F and \x0A), sorted the lists and
compared them. There are 193 differences.


                                                           /L/e/k/t/u


--- redhat.doc	Wed Jun 12 15:43:18 2002
+++ windows.doc	Wed Jun 12 15:43:06 2002

-compose-chars-after-function
-compose-region-internal
-compose-string-internal
-composition-function-table
-cross-disabled-images
-do-applescript
-dos-codepage
-dos-country-code
-dos-decimal-point
-dos-display-scancodes
-dos-hyper-key
-dos-keyboard-layout
-dos-keypad-mode
-dos-super-key
-dos-timezone-offset
-dos-unsupported-char-glyph
-dos-version
-dos-windows-version
-find-composition-internal
-font-lock-defaults
-font-lock-defaults-alist
-font-lock-function
-font-lock-global-modes
-font-lock-mode
-font-lock-mode-hook
-font-lock-multiline
-font-lock-set-defaults
-global-font-lock-mode
-global-font-lock-mode-hook
-handle-save-session
-imagep
-insert-startup-screen
-int86
-lookup-image
-mac-command-key-is-meta
-mac-cut-function
-mac-file-name-to-posix
-mac-keyboard-text-encoding
-mac-paste-function
-motif-version-string
-msdos-downcase-filename
-msdos-long-file-names
-msdos-memget
-msdos-memput
-msdos-mouse-disable
-msdos-mouse-enable
-msdos-mouse-init
-msdos-mouse-p
-msdos-remember-default-colors
-msdos-set-keyboard
-msdos-set-mouse-buttons
-play-sound-internal
-posix-file-name-to-mac
-recent-doskeys
-selection-converter-alist
+set-cursor-size
+set-message-beep
+set-screen-color
-sit-for-millisecs
-sleep-for-millisecs
-sun-change-cursor-icon
-sun-get-selection
-sun-menu-internal
-sun-set-selection
-sun-window-init
-turn-on-font-lock
-ucs-8859-1-encode-table
-ucs-8859-14-encode-table
-ucs-8859-15-encode-table
-ucs-8859-2-encode-table
-ucs-8859-3-encode-table
-ucs-8859-4-encode-table
-ucs-8859-5-encode-table
-ucs-8859-7-encode-table
-ucs-8859-8-encode-table
-ucs-8859-9-encode-table
-ucs-fragment-8859
-ucs-insert
-ucs-mule-8859-to-mule-unicode
-ucs-mule-8859-to-ucs-table
-ucs-unify-8859
-unify-8859-on-decoding-mode
-unify-8859-on-decoding-mode-hook
-unify-8859-on-encoding-mode
-unify-8859-on-encoding-mode-hook
-update-display
+w32-allow-system-shell
+w32-alt-is-meta
+w32-apps-modifier
+w32-bdf-filename-alist
+w32-capslock-is-shiftlock
+w32-charset-info-alist
+w32-close-clipboard
+w32-color-map
+w32-default-color-map
+w32-define-rgb-color
+w32-downcase-file-names
+w32-empty-clipboard
+w32-enable-caps-lock
+w32-enable-num-lock
+w32-enable-palette
+w32-enable-synthesized-fonts
+w32-enable-unicode-output
+w32-extra-charsets-defined
+w32-find-bdf-fonts
+w32-fixed-font-alist
+w32-focus-frame
+w32-generate-fake-inodes
+w32-get-clipboard-data
+w32-get-codepage-charset
+w32-get-console-codepage
+w32-get-console-output-codepage
+w32-get-current-locale-id
+w32-get-default-locale-id
+w32-get-keyboard-layout
+w32-get-locale-info
+w32-get-true-file-attributes
+w32-get-valid-codepages
+w32-get-valid-keyboard-layouts
+w32-get-valid-locale-ids
+w32-grab-focus-on-raise
+w32-has-winsock
+w32-list-proportional-fonts
+w32-load-color-file
+w32-long-file-name
+w32-lwindow-modifier
+w32-mouse-button-tolerance
+w32-mouse-move-interval
+w32-num-mouse-buttons
+w32-open-clipboard
+w32-pass-alt-to-system
+w32-pass-extra-mouse-buttons-to-system
+w32-pass-lwindow-to-system
+w32-pass-rwindow-to-system
+w32-phantom-key-code
+w32-pipe-read-delay
+w32-quit-key
+w32-quote-process-args
+w32-recognize-altgr
+w32-reconstruct-hot-key
+w32-register-hot-key
+w32-registered-hot-keys
+w32-rwindow-modifier
+w32-scroll-lock-modifier
+w32-select-font
+w32-send-sys-command
+w32-set-clipboard-data
+w32-set-console-codepage
+w32-set-console-output-codepage
+w32-set-current-locale
+w32-set-keyboard-layout
+w32-set-process-priority
+w32-shell-execute
+w32-short-file-name
+w32-start-process-inherit-error-mode
+w32-start-process-share-console
+w32-start-process-show-window
+w32-strict-fontnames
+w32-strict-painting
+w32-swap-mouse-buttons
+w32-system-shells
+w32-toggle-lock-key
+w32-unicode-charset-defined
+w32-unload-winsock
+w32-unregister-hot-key
+w32-use-full-screen-buffer
+w32-use-visible-system-caret
+w32-use-w32-font-dialog
-x-alt-keysym
-x-autoselect-window
-x-backspace-delete-keys-p
-x-disown-selection-internal
-x-focus-frame
-x-get-cut-buffer-internal
-x-get-selection-internal
-x-hyper-keysym
-x-lost-selection-hooks
-x-meta-keysym
-x-mode-pointer-shape
-x-nontext-pointer-shape
-x-own-selection-internal
-x-resource-class
-x-rotate-cut-buffers-internal
+x-select-enable-clipboard
-x-selection-owner-p
-x-selection-timeout
-x-sent-selection-hooks
-x-session-id
-x-session-previous-id
-x-store-cut-buffer-internal
-x-super-keysym

Re: Building emacs with and without X -- packaging question.

[Eli Zaretskii]

On Wed, 12 Jun 2002, Juanma Barranquero wrote:

> I've bootstrapped HEAD on Windows and on a RedHat 7.2, I've extracted
> the symbols from each (text between \x1F and \x0A), sorted the lists and
> compared them. There are 193 differences.

Thanks for the footwork.

Could you please identify the reasons for these differences?  That is, 
what modules are present in the list submitted to make-docfile on each 
platform, and which explain these differences?

AFAICS, there are some platform-specific files (that's where those w32-* 
and dos-* symbols come from); the question is whether all platforms 
should have the doc strings of those.

Then there are some x-* symbols which I thought should be in all 
versions.

And then there are some symbols like ucs-* and others which should have 
been in DOC on all systems--can you see why they aren't?

Re: Building emacs with and without X -- packaging question.

[Juanma Barranquero]

On Thu, 13 Jun 2002 08:21:17 +0300 (IDT), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> That is, what modules are present in the list submitted to make-docfile on each 
> platform, and which explain these differences?

See the list below.

> the question is whether all platforms should have the doc strings of those.

That seems like a good idea, but it'll pose a maintenance burden, I
think.

> Then there are some x-* symbols which I thought should be in all 
> versions.

All x-files have a corresponding w32-file, but I suppose they don't
always define the exact same symbols.

> And then there are some symbols like ucs-* and others which should have 
> been in DOC on all systems--can you see why they aren't?

Don't know why the relevant files (like lisp/international/ucs-tables)
aren't included. An oversight, perhaps?

                                                           /L/e/k/t/u



--- redhat.lst	Thu Jun 13 11:49:53 2002
+++ windows.lst	Thu Jun 13 11:49:40 2002
-src/atimer
+src/alloca
-src/composite
-src/dosfns
+src/gmalloc
+src/lastfile
-src/mac
-src/macfns
-src/macmenu
-src/macterm
-src/md5
-src/msdos
+src/ralloc
-src/sound
-src/sunfns
+src/termcap
+src/tparam
-src/unexelf
+src/unexw32
+src/vm-limit
+src/w32
+src/w32console
+src/w32fns
+src/w32heap
+src/w32inevt
+src/w32menu
+src/w32proc
+src/w32reg
+src/w32select
+src/w32term
+src/w32xfns
-src/xfns
-src/xmenu
-src/xrdb
-src/xselect
-src/xsmfns
-src/xterm
-lisp/font-core
-lisp/international/ucs-tables
+lisp/w32-vars

Re: Building emacs with and without X -- packaging question.

[Eli Zaretskii]

On Thu, 13 Jun 2002, Juanma Barranquero wrote:

> On Thu, 13 Jun 2002 08:21:17 +0300 (IDT), Eli Zaretskii <eliz@is.elta.co.il> wrote:
> 
> > That is, what modules are present in the list submitted to make-docfile on each 
> > platform, and which explain these differences?
> 
> See the list below.

Thanks!

> > the question is whether all platforms should have the doc strings of those.
> 
> That seems like a good idea, but it'll pose a maintenance burden, I
> think.

What maintenance burden did you have in mind?  All we need is make sure 
make-docfile is invoked with the same list of files on all platforms.

> > And then there are some symbols like ucs-* and others which should have 
> > been in DOC on all systems--can you see why they aren't?
> 
> Don't know why the relevant files (like lisp/international/ucs-tables)
> aren't included. An oversight, perhaps?

The interesting question is why are doc strings from ucs-tables seen on 
Unix and GNU/Linux systems, but not on Windows?

Re: Building emacs with and without X -- packaging question.

[Juanma Barranquero]

On Thu, 13 Jun 2002 14:42:05 +0300 (IDT), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> What maintenance burden did you have in mind?  All we need is make sure 
> make-docfile is invoked with the same list of files on all platforms.

Hmm, I'm not sure, but I've seen that DOC data is extracted sometimes
from .el files and others from .elc, and from .c files in Windows, but .o
files in GNU/Linux...

OTOH, there are .elc and .o/.obj files which conceptually cannot be
built on Windows, because they require support programs or libraries not
present, etc. It sounds complicated because we'll have to maintain lists
and know for each environment if the data must be extracted from .el or
.elc, .o/.obj or .c or whatever.

Also, I think in Unix/Linux environments the list of files can be
perhaps automatically maintained, but Windows shells are pathetic and
the list is manually constructed.

But I digress. If you think it's better, we can certainly try it and see
if is works...

> The interesting question is why are doc strings from ucs-tables seen on 
> Unix and GNU/Linux systems, but not on Windows?

I don't understand. Are you asking why the doc strings are not seen on
Windows, or why lisp/international/ucs-tables is not used to generate
DOC on Windows?


                                                           /L/e/k/t/u

Re: Building emacs with and without X -- packaging question.

[Eli Zaretskii]

On Thu, 13 Jun 2002, Juanma Barranquero wrote:

> On Thu, 13 Jun 2002 14:42:05 +0300 (IDT), Eli Zaretskii <eliz@is.elta.co.il> wrote:
> 
> > What maintenance burden did you have in mind?  All we need is make sure 
> > make-docfile is invoked with the same list of files on all platforms.
> 
> Hmm, I'm not sure, but I've seen that DOC data is extracted sometimes
> from .el files and others from .elc, and from .c files in Windows, but .o
> files in GNU/Linux...

These are technicalities.  You will see that make-docfile always reads 
the *.c files, on all platforms, even if you submit *.o files to it.  I'm 
not quite sure why the Windows Makefile's use *.c files directly, but I'm 
guessing that it's something trivial, like the fact that there are no *.o 
files on Windows.

> OTOH, there are .elc and .o/.obj files which conceptually cannot be
> built on Windows, because they require support programs or libraries not
> present, etc.

The distribution always comes with all *.c files and with all *.elc files 
already compiled.  So there should be no problem to build a 
system-independent DOC file.  All we need is decide on the contents of 
the various lists of files used by src/Makefile.in to build DOC.

> Also, I think in Unix/Linux environments the list of files can be
> perhaps automatically maintained, but Windows shells are pathetic and
> the list is manually constructed.

That problem already exists.  The issue we are discussing doesn't add any 
significant addition to it.

> > The interesting question is why are doc strings from ucs-tables seen on 
> > Unix and GNU/Linux systems, but not on Windows?
> 
> I don't understand. Are you asking why the doc strings are not seen on
> Windows, or why lisp/international/ucs-tables is not used to generate
> DOC on Windows?

The latter.

Re: Building emacs with and without X -- packaging question.

[Juanma Barranquero]

On Thu, 13 Jun 2002 17:03:56 +0300 (IDT), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> These are technicalities. [...] All we need is decide on the contents of 
> the various lists of files used by src/Makefile.in to build DOC.

OK.

> The latter.

A simple oversight, I'd say. ucs-tables was added to src/Makefile.in by
Stefan Monnier on 2002/04/02; I suppose he didn't think of adding it to
makefile.w32-in or whatever. font-core.el is in a similar situation: it
was added to src/Makefile.in 2002/05/21, and it's not used on the Windows
DOC.


                                                           /L/e/k/t/u

Re: Building emacs with and without X -- packaging question.

[Eli Zaretskii]

On Thu, 13 Jun 2002, Juanma Barranquero wrote:

> A simple oversight, I'd say. ucs-tables was added to src/Makefile.in by
> Stefan Monnier on 2002/04/02; I suppose he didn't think of adding it to
> makefile.w32-in or whatever. font-core.el is in a similar situation: it
> was added to src/Makefile.in 2002/05/21, and it's not used on the Windows
> DOC.

It figures.  Could you please make the necessary changes in the Windows 
makefile's?

Re: Building emacs with and without X -- packaging question.

[Juanma Barranquero]

On Thu, 13 Jun 2002 18:16:13 +0300 (IDT), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> It figures.  Could you please make the necessary changes in the Windows 
> makefile's?

Done (for lisp/international/ucs-tables.elc and lisp/font-core.elc).


                                                           /L/e/k/t/u

Re: Building emacs with and without X -- packaging question.

[Richard Stallman]

    A simple oversight, I'd say. ucs-tables was added to src/Makefile.in by
    Stefan Monnier on 2002/04/02; I suppose he didn't think of adding it to
    makefile.w32-in or whatever. font-core.el is in a similar situation: it
    was added to src/Makefile.in 2002/05/21, and it's not used on the Windows
    DOC.

This illustrates why it will be difficult to keep the DOC file in sync
between Windows and other systems.

In this case, the discrepancies were outright errors; they resulted in
a DOC file that was simply wrong on Windows.  Fixing these bugs was
necessary regardless of whether we want the DOC file to be identical
on Windows and on GNU|Unix.  Perhaps this means that checking for
differences in the DOC files is a useful way to find places where
we omitted a change that needed to be made in makefile.w32.
Thus, it may be that insisting the DOC file must be identical on
all platforms actually improves maintenance.

Re: Building emacs with and without X -- packaging question.

[Eli Zaretskii]

> Date: Fri, 14 Jun 2002 09:47:19 -0600 (MDT)
> From: Richard Stallman <rms@gnu.org>
> 
> it may be that insisting the DOC file must be identical on
> all platforms actually improves maintenance.

Indeed.

Re: Building emacs with and without X -- packaging question.

[Richard Stallman]

    I've bootstrapped HEAD on Windows and on a RedHat 7.2, I've extracted
    the symbols from each (text between \x1F and \x0A), sorted the lists and
    compared them. There are 193 differences.

I can see why there might be many differences between Windows and GNU|Unix.
Different makefiles are used on those two systems.

We have tried to make sure that DOC is the same on all Unix-like
systems and regardless of options used.  Someone just found a bug in
that, but the fix was simple.  Keeping DOC the same on these systems
is worth doing.

Making DOC be the same on Windows as on Unix-like systems is possible,
but it will be somewhat more work, and more costly in a way.  Is it
important to do this?  Are there users that want to share the DOC file
between Windows machines and GNU-like systems?

Re: Building emacs with and without X -- packaging question.

[Juanma Barranquero]

On Thu, 13 Jun 2002 15:47:18 -0600 (MDT), Richard Stallman <rms@gnu.org> wrote:

> Making DOC be the same on Windows as on Unix-like systems is possible,
> but it will be somewhat more work, and more costly in a way.  Is it
> important to do this? Are there users that want to share the DOC file
> between Windows machines and GNU-like systems?

Probably no, there aren't many users who want tho share DOC between
Windows and GNU systems.

IMHO, the only single advantage from making the DOCs equal is trying to
minimize cases like the one showcased yesterday, where files that should
be in all systems are inadvertedly left out.

But I cannot judge if that makes the maintaining effort worse than the
posible inconvenience.


                                                           /L/e/k/t/u

Re: Building emacs with and without X -- packaging question.

[Eli Zaretskii]

> Date: Thu, 13 Jun 2002 15:47:18 -0600 (MDT)
> From: Richard Stallman <rms@gnu.org>
> 
> Making DOC be the same on Windows as on Unix-like systems is possible,
> but it will be somewhat more work, and more costly in a way.  Is it
> important to do this?  Are there users that want to share the DOC file
> between Windows machines and GNU-like systems?

I don't think there will be many users who will need that, but it's
quite possible that someone has an Emacs installation on a networked
disk exported to both Unix and Windows systems.

Since the maintainers of the Windows port need to sync the Makefile's
anyhow, I think we should try to keep the DOC files identical while
at that.

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

Eli Zaretskii <eliz@is.elta.co.il> writes:

>> Ok.  Turns out it's very small.
>
> Indeed.  It sounds like adding fontset.o to SOME_MACHINE_OBJECTS on 
> src/Makefile.in should fix that.  Can you try?
>
> I think we also saw similar problems with the Windows port, so perhaps 
> someone who can build a Windows version could compare the DOC file with 
> the Unix version, and see whether more files are missing from the 
> respective lists in src/Makefile.in.

OK, so I'll see about applying this fix.  Given that, what would be
the most appropriate way to build the X and non-X binaries?  Should I
just go through a full clean, reconfigure, and make for each one, or
is there a more efficient approach that would still be considered
correct.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Eli Zaretskii]

> From: Rob Browning <rlb@defaultvalue.org>
> Date: Thu, 20 Jun 2002 16:45:41 -0500
> 
> what would be
> the most appropriate way to build the X and non-X binaries?  Should I
> just go through a full clean, reconfigure, and make for each one, or
> is there a more efficient approach that would still be considered
> correct.

I don't think there's a way except make distclean, configure (with
appropriate switches), then make.

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> I don't think there's a way except make distclean, configure (with
> appropriate switches), then make.

OK, that's fine with me.  Just wanted to make sure there wasn't an
official shortcut -- figured the umpteen autobuilders (incl 68k) might
appreciate it :>

Thanks.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> I don't think there's a way except make distclean, configure (with
> appropriate switches), then make.

OK, thanks.

Working from the latest official 21 release I added fontset.o to
SOME_MACHINE_OBJECTS and then built two trees, one with X and one
without.  Then I ran a diff on the two trees.  Ignoring all the config
related files and the files that only differ by a "Date:" (mostly
quail .el files) I still find some differences and wanted to make sure
those were OK.  Looks like cus-load.el differs, and so do some
executables and libraries (the latter two of which I expect are fine).

Below is the diff for cus-load.el.  Since this is a file that is
normally installed, so how should it be handled between the two emacs
packages (X and no-X)?

diff -x Makefile.c -x config.h -x epaths.h -x *.o -x fns-21.2.1.el -x config.status -x config.log -x Makefile -x config.cache -ruN debian/tmp-build-emacs/lisp/cus-load.el debian/tmp-build-emacs-nox/lisp/cus-load.el
--- debian/tmp-build-emacs/lisp/cus-load.el	Sat Jun 22 01:17:18 2002
+++ debian/tmp-build-emacs-nox/lisp/cus-load.el	Sat Jun 22 01:25:32 2002
@@ -140,7 +140,7 @@
 (put 'feedmail-spray 'custom-loads '("feedmail"))
 (put 'idlwave-external-programs 'custom-loads '("idlwave"))
 (put 'strokes 'custom-loads '("strokes"))
-(put 'mouse 'custom-loads '("faces" "mouse" "menu-bar" "avoid" "mouse-sel" "msb" "mwheel" "strokes" "tooltip" "goto-addr" "artist"))
+(put 'mouse 'custom-loads '("faces" "menu-bar" "avoid" "mouse-sel" "mouse" "msb" "mwheel" "strokes" "tooltip" "goto-addr" "artist"))
 (put 'nnmail-various 'custom-loads '("nnmail"))
 (put 'smiley 'custom-loads '("smiley-ems"))
 (put 'extensions 'custom-loads '("generic" "time-stamp" "wid-edit" "cust-print" "eldoc" "page-ext"))
@@ -163,7 +163,7 @@
 (put 'reftex-making-and-inserting-labels 'custom-loads '("reftex-vars"))
 (put 'calendar-hooks 'custom-loads '("calendar"))
 (put 'mailalias 'custom-loads '("mailalias"))
-(put 'frames 'custom-loads '("frame" "faces" "scroll-bar" "menu-bar" "desktop" "ediff-wind" "imenu" "two-column" "rsz-mini"))
+(put 'frames 'custom-loads '("frame" "faces" "menu-bar" "desktop" "ediff-wind" "imenu" "two-column" "rsz-mini"))
 (put 'gnus-server 'custom-loads '("gnus"))
 (put 'paren-showing 'custom-loads '("paren"))
 (put 'dos-fns 'custom-loads '("dos-vars"))
@@ -998,8 +998,6 @@
 (custom-put-if-not 'custom-comment-face 'group-documentation nil)
 (custom-put-if-not 'custom-raised-buttons 'custom-version "21.1")
 (custom-put-if-not 'custom-raised-buttons 'standard-value t)
-(custom-put-if-not 'gnus-article-x-face-command 'custom-version "21.1")
-(custom-put-if-not 'gnus-article-x-face-command 'standard-value t)
 (custom-put-if-not 'gnus-inhibit-user-auto-expire 'custom-version "21.1")
 (custom-put-if-not 'gnus-inhibit-user-auto-expire 'standard-value t)
 (custom-put-if-not 'show-paren-ring-bell-on-mismatch 'custom-version "20.3")

I presume these differences are probably expected and OK:

Binary files debian/tmp-build-emacs/lib-src/b2m and debian/tmp-build-emacs-nox/lib-src/b2m differ
Binary files debian/tmp-build-emacs/lib-src/ctags and debian/tmp-build-emacs-nox/lib-src/ctags differ
Binary files debian/tmp-build-emacs/lib-src/cvtmail and debian/tmp-build-emacs-nox/lib-src/cvtmail differ
Binary files debian/tmp-build-emacs/lib-src/digest-doc and debian/tmp-build-emacs-nox/lib-src/digest-doc differ
Binary files debian/tmp-build-emacs/lib-src/ebrowse and debian/tmp-build-emacs-nox/lib-src/ebrowse differ
Binary files debian/tmp-build-emacs/lib-src/emacsclient and debian/tmp-build-emacs-nox/lib-src/emacsclient differ
Binary files debian/tmp-build-emacs/lib-src/emacsserver and debian/tmp-build-emacs-nox/lib-src/emacsserver differ
Binary files debian/tmp-build-emacs/lib-src/etags and debian/tmp-build-emacs-nox/lib-src/etags differ
Binary files debian/tmp-build-emacs/lib-src/fakemail and debian/tmp-build-emacs-nox/lib-src/fakemail differ
Binary files debian/tmp-build-emacs/lib-src/hexl and debian/tmp-build-emacs-nox/lib-src/hexl differ
Binary files debian/tmp-build-emacs/lib-src/make-docfile and debian/tmp-build-emacs-nox/lib-src/make-docfile differ
Binary files debian/tmp-build-emacs/lib-src/movemail and debian/tmp-build-emacs-nox/lib-src/movemail differ
Binary files debian/tmp-build-emacs/lib-src/profile and debian/tmp-build-emacs-nox/lib-src/profile differ
Binary files debian/tmp-build-emacs/lib-src/sorted-doc and debian/tmp-build-emacs-nox/lib-src/sorted-doc differ
Binary files debian/tmp-build-emacs/lib-src/test-distrib and debian/tmp-build-emacs-nox/lib-src/test-distrib differ
Binary files debian/tmp-build-emacs/lib-src/yow and debian/tmp-build-emacs-nox/lib-src/yow differ
Binary files debian/tmp-build-emacs/lwlib/liblw.a and debian/tmp-build-emacs-nox/lwlib/liblw.a differ
Binary files debian/tmp-build-emacs/src/emacs and debian/tmp-build-emacs-nox/src/emacs differ
Binary files debian/tmp-build-emacs/src/emacs-21.2.1 and debian/tmp-build-emacs-nox/src/emacs-21.2.1 differ
Binary files debian/tmp-build-emacs/src/prefix-args and debian/tmp-build-emacs-nox/src/prefix-args differ
Binary files debian/tmp-build-emacs/src/temacs and debian/tmp-build-emacs-nox/src/temacs differ

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Richard Stallman]

These differences in cus-load.el are strange.  The code that
updates it is in lisp/Makefile.in, in the custom-deps target;
it works by invoking Lisp code in cus-dep.el.  This code works
by scanning a list of directories.  Can you arrange to see the
list of directories in both cases, and compare them?
If they are different, can you find out where the difference
originates from?

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

Richard Stallman <rms@gnu.org> writes:

> Can you arrange to see the list of directories in both cases, and
> compare them?  If they are different, can you find out where the
> difference originates from?

Sure.

I changed the lisp/Makefile.in custom-deps rule as follows.  The only
difference it to write a timestamped file containing $$wins to /tmp.
The resulting files (one from the X build, and one from the no-X
build) were identical, but the cus-load.el files in the two resulting
build trees were still different.

custom-deps: cus-load.el doit
	wd=$(lisp); $(setwins); \
	echo Directories: $$wins; \
	echo $$wins | sort | perl -pe 's/ /\n/gmo' > /tmp/cdep-$$(datestamp); \
	$(EMACS) $(EMACSOPT) -l cus-dep -f custom-make-dependencies $$wins

If it matters, I perform the two builds in separate build directories
using the standard "${srcdir}/configure ..." approach, and I perform a
"make boostrap" for each.

However, before we go any further, let me try this again using the
unmodified upstream source.  I should have thought to do that
initially, but I didn't.  So let me make sure this isn't being caused
by any of the debian diffs.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> However, before we go any further, let me try this again using the
> unmodified upstream source.  I should have thought to do that
> initially, but I didn't.  So let me make sure this isn't being caused
> by any of the debian diffs.

OK, checked with clean upstream+leim 21.2 source, and ended up with
essentially the same diffs.  Ignoring binaries and "Date: induced"
quail .el differences, we have:

diff -x Makefile.c -x config.h -x epaths.h -x *.o -x fns-21.2.1.el -x config.status -x config.log -x Makefile -x config.cache -ruN x/lisp/cus-load.el nox/lisp/cus-load.el
--- x/lisp/cus-load.el	Mon Jun 24 09:37:42 2002
+++ nox/lisp/cus-load.el	Mon Jun 24 09:45:29 2002
@@ -140,7 +140,7 @@
 (put 'feedmail-spray 'custom-loads '("feedmail"))
 (put 'idlwave-external-programs 'custom-loads '("idlwave"))
 (put 'strokes 'custom-loads '("strokes"))
-(put 'mouse 'custom-loads '("faces" "mouse" "menu-bar" "avoid" "mouse-sel" "msb" "mwheel" "strokes" "tooltip" "goto-addr" "artist"))
+(put 'mouse 'custom-loads '("faces" "menu-bar" "avoid" "mouse-sel" "mouse" "msb" "mwheel" "strokes" "tooltip" "goto-addr" "artist"))
 (put 'nnmail-various 'custom-loads '("nnmail"))
 (put 'smiley 'custom-loads '("smiley-ems"))
 (put 'extensions 'custom-loads '("generic" "time-stamp" "wid-edit" "cust-print" "eldoc" "page-ext"))
@@ -163,7 +163,7 @@
 (put 'reftex-making-and-inserting-labels 'custom-loads '("reftex-vars"))
 (put 'calendar-hooks 'custom-loads '("calendar"))
 (put 'mailalias 'custom-loads '("mailalias"))
-(put 'frames 'custom-loads '("frame" "faces" "scroll-bar" "menu-bar" "desktop" "ediff-wind" "imenu" "two-column" "rsz-mini"))
+(put 'frames 'custom-loads '("frame" "faces" "menu-bar" "desktop" "ediff-wind" "imenu" "two-column" "rsz-mini"))
 (put 'gnus-server 'custom-loads '("gnus"))
 (put 'paren-showing 'custom-loads '("paren"))
 (put 'dos-fns 'custom-loads '("dos-vars"))
@@ -998,8 +998,6 @@
 (custom-put-if-not 'custom-comment-face 'group-documentation nil)
 (custom-put-if-not 'custom-raised-buttons 'custom-version "21.1")
 (custom-put-if-not 'custom-raised-buttons 'standard-value t)
-(custom-put-if-not 'gnus-article-x-face-command 'custom-version "21.1")
-(custom-put-if-not 'gnus-article-x-face-command 'standard-value t)
 (custom-put-if-not 'gnus-inhibit-user-auto-expire 'custom-version "21.1")
 (custom-put-if-not 'gnus-inhibit-user-auto-expire 'standard-value t)
 (custom-put-if-not 'show-paren-ring-bell-on-mismatch 'custom-version "20.3")

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Richard Stallman]

    I changed the lisp/Makefile.in custom-deps rule as follows.  The only
    difference it to write a timestamped file containing $$wins to /tmp.
    The resulting files (one from the X build, and one from the no-X
    build) were identical, but the cus-load.el files in the two resulting
    build trees were still different.

Peculiar.  I guess the next step is to put some tracing code in
cus-dep.el itself.

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

Richard Stallman <rms@gnu.org> writes:

> Peculiar.  I guess the next step is to put some tracing code in
> cus-dep.el itself.

Right -- I was planning to as soon as I have a chance to work on this
some more.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Stefan Monnier]

>     I changed the lisp/Makefile.in custom-deps rule as follows.  The only
>     difference it to write a timestamped file containing $$wins to /tmp.
>     The resulting files (one from the X build, and one from the no-X
>     build) were identical, but the cus-load.el files in the two resulting
>     build trees were still different.
> 
> Peculiar.  I guess the next step is to put some tracing code in
> cus-dep.el itself.

IIRC It's because cus-dep.el loads files and the load order is important.
The set of preloaded files is different, so the load order is different
so the resulting cus-load.el is different.
This is especially the case when one variable is defcustom'd in two
files (as is the case for c-indent-level), but I suspect it's also
the case for other situations.


	Stefan

Re: Building emacs with and without X -- packaging question.

[Eli Zaretskii]

On Mon, 24 Jun 2002, Stefan Monnier wrote:

> IIRC It's because cus-dep.el loads files and the load order is important.
> The set of preloaded files is different, so the load order is different
> so the resulting cus-load.el is different.

That's true, but some of the differences are not just order differences.  
For example, scroll-bar doesn't appear in one custom-load, and 
gnus-article-x-face-command doesn't appear in the non-X version at all.

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> That's true, but some of the differences are not just order differences.  
> For example, scroll-bar doesn't appear in one custom-load, and 
> gnus-article-x-face-command doesn't appear in the non-X version at all.

Yep, I noticed that.  So is this is a difference that's supposed to
exist between the X and non-X versions?  If so, then is there a way we
could (and would want to) fix this to allow the two versions to
coexist peacefully?

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Eli Zaretskii]

On Tue, 25 Jun 2002, Rob Browning wrote:

> Eli Zaretskii <eliz@is.elta.co.il> writes:
> 
> > That's true, but some of the differences are not just order differences.  
> > For example, scroll-bar doesn't appear in one custom-load, and 
> > gnus-article-x-face-command doesn't appear in the non-X version at all.
> 
> Yep, I noticed that.  So is this is a difference that's supposed to
> exist between the X and non-X versions?  If so, then is there a way we
> could (and would want to) fix this to allow the two versions to
> coexist peacefully?

I tend to think that cus-load should not depend on the configuration 
options, unless doing so would cause trouble.

Re: Building emacs with and without X -- packaging question.

[Richard Stallman]

      So is this is a difference that's supposed to
    exist between the X and non-X versions?

There is no need for them to be different, so we may as well make them
the same.  Can you figure out the cause of the remaining differences?

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

Richard Stallman <rms@gnu.org> writes:

> There is no need for them to be different, so we may as well make them
> the same.  Can you figure out the cause of the remaining differences?

Certainly -- it's on my to do list.  I'll work on it as I have time.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Richard Stallman]

    IIRC It's because cus-dep.el loads files and the load order is important.
    The set of preloaded files is different, so the load order is different
    so the resulting cus-load.el is different.

How about if we make cus-load.el start by sorting the files by ASCII
order.  That would eliminate all differences that result from this
cause.

However, the cause of the other differences remains to be determined.

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> Below is the diff for cus-load.el.

I've figured out how to fix cus-load.el to fix spurious "sort-order"
based diffs like this:

>  (put 'strokes 'custom-loads '("strokes"))
> -(put 'mouse 'custom-loads '("faces" "mouse" "menu-bar" "avoid" "mouse-sel" "msb" "mwheel" "strokes" "tooltip" "goto-addr" "artist"))
> +(put 'mouse 'custom-loads '("faces" "menu-bar" "avoid" "mouse-sel" "mouse" "msb" "mwheel" "strokes" "tooltip" "goto-addr" "artist"))
>  (put 'nnmail-various 'custom-loads '("nnmail"))

and I'll send the patch once I've cleaned it up.  Given that patch,
the lread.c fix, and the addition of fontset.o to
SOME_MACHINE_OBJECTS, it looks like the DOC files are equivalent.

One thing I was curious about though -- what usually causes two DOC
files to be built?  My --with-x=yes tree has two DOC and two
lib-src/fns-*.el files, but my --with-x=no tree has only one of each,
even though I believe I used the same sequence of
"../build-src/configure ...; make bootstrap; make" commands for each.

With respect to the differences between the X and non-X build trees,
I've included what remains below.  I "-x" ignore the DOC-21.2.2 and
fns-21.2.2.el files since they only exist in the non-X tree and the .2
versions are identical to the .1 versions in that tree.

Please tell me if you any of the remaining differences matter, and how
I should go about fixing them.  I've deleted the diff lines for the
quail "Date: only" diffs, after the example.  Overall, other than the
quail differences, and some expected binary differences, it looks like
there are still a few cus-dep.el differences, and some fns-*.el
differences.

Thanks

diff -x Makefile.c -x config.h -x epaths.h -x *.o -x DOC-21.2.2 -x
  fns-21.2.2.el -x config.status -x config.log -x Makefile -x
  config.cache -x debian -x DEBIAN -ruN tmp-build-emacs tmp-build-emacs-nox

--- tmp-build-emacs/leim/quail/4Corner.el	Wed Jul 31 13:42:00 2002
+++ tmp-build-emacs-nox/leim/quail/4Corner.el	Wed Jul 31 13:52:09 2002
@@ -1,5 +1,5 @@
 ;; Quail package `chinese-4corner' generated by the command `titdic-convert'
-;;	Date: Wed Jul 31 13:42:00 2002
+;;	Date: Wed Jul 31 13:52:09 2002
 ;;	Original TIT dictionary file: 4Corner.tit
 
 ;;; Comment:
Binary files tmp-build-emacs/leim/quail/4Corner.elc and tmp-build-emacs-nox/leim/quail/4Corner.elc differ
--- tmp-build-emacs/leim/quail/ARRAY30.el	Wed Jul 31 13:42:01 2002
+++ tmp-build-emacs-nox/leim/quail/ARRAY30.el	Wed Jul 31 13:52:10 2002
Binary files tmp-build-emacs/leim/quail/ARRAY30.elc and tmp-build-emacs-nox/leim/quail/ARRAY30.elc differ
--- tmp-build-emacs/leim/quail/CCDOSPY.el	Wed Jul 31 13:42:01 2002
+++ tmp-build-emacs-nox/leim/quail/CCDOSPY.el	Wed Jul 31 13:52:10 2002
Binary files tmp-build-emacs/leim/quail/CCDOSPY.elc and tmp-build-emacs-nox/leim/quail/CCDOSPY.elc differ
--- tmp-build-emacs/leim/quail/CTLau-b5.el	Wed Jul 31 13:42:08 2002
+++ tmp-build-emacs-nox/leim/quail/CTLau-b5.el	Wed Jul 31 13:52:16 2002
Binary files tmp-build-emacs/leim/quail/CTLau-b5.elc and tmp-build-emacs-nox/leim/quail/CTLau-b5.elc differ
--- tmp-build-emacs/leim/quail/CTLau.el	Wed Jul 31 13:42:05 2002
+++ tmp-build-emacs-nox/leim/quail/CTLau.el	Wed Jul 31 13:52:13 2002
Binary files tmp-build-emacs/leim/quail/CTLau.elc and tmp-build-emacs-nox/leim/quail/CTLau.elc differ
--- tmp-build-emacs/leim/quail/ECDICT.el	Wed Jul 31 13:42:01 2002
+++ tmp-build-emacs-nox/leim/quail/ECDICT.el	Wed Jul 31 13:52:10 2002
Binary files tmp-build-emacs/leim/quail/ECDICT.elc and tmp-build-emacs-nox/leim/quail/ECDICT.elc differ
--- tmp-build-emacs/leim/quail/ETZY.el	Wed Jul 31 13:42:01 2002
+++ tmp-build-emacs-nox/leim/quail/ETZY.el	Wed Jul 31 13:52:10 2002
Binary files tmp-build-emacs/leim/quail/ETZY.elc and tmp-build-emacs-nox/leim/quail/ETZY.elc differ
--- tmp-build-emacs/leim/quail/PY-b5.el	Wed Jul 31 13:42:01 2002
+++ tmp-build-emacs-nox/leim/quail/PY-b5.el	Wed Jul 31 13:52:10 2002
Binary files tmp-build-emacs/leim/quail/PY-b5.elc and tmp-build-emacs-nox/leim/quail/PY-b5.elc differ
--- tmp-build-emacs/leim/quail/PY.el	Wed Jul 31 13:42:11 2002
+++ tmp-build-emacs-nox/leim/quail/PY.el	Wed Jul 31 13:52:19 2002
Binary files tmp-build-emacs/leim/quail/PY.elc and tmp-build-emacs-nox/leim/quail/PY.elc differ
--- tmp-build-emacs/leim/quail/Punct-b5.el	Wed Jul 31 13:42:01 2002
+++ tmp-build-emacs-nox/leim/quail/Punct-b5.el	Wed Jul 31 13:52:10 2002
Binary files tmp-build-emacs/leim/quail/Punct-b5.elc and tmp-build-emacs-nox/leim/quail/Punct-b5.elc differ
--- tmp-build-emacs/leim/quail/Punct.el	Wed Jul 31 13:42:01 2002
+++ tmp-build-emacs-nox/leim/quail/Punct.el	Wed Jul 31 13:52:10 2002
Binary files tmp-build-emacs/leim/quail/Punct.elc and tmp-build-emacs-nox/leim/quail/Punct.elc differ
--- tmp-build-emacs/leim/quail/QJ-b5.el	Wed Jul 31 13:42:01 2002
+++ tmp-build-emacs-nox/leim/quail/QJ-b5.el	Wed Jul 31 13:52:10 2002
Binary files tmp-build-emacs/leim/quail/QJ-b5.elc and tmp-build-emacs-nox/leim/quail/QJ-b5.elc differ
--- tmp-build-emacs/leim/quail/QJ.el	Wed Jul 31 13:42:01 2002
+++ tmp-build-emacs-nox/leim/quail/QJ.el	Wed Jul 31 13:52:10 2002
Binary files tmp-build-emacs/leim/quail/QJ.elc and tmp-build-emacs-nox/leim/quail/QJ.elc differ
--- tmp-build-emacs/leim/quail/SW.el	Wed Jul 31 13:42:01 2002
+++ tmp-build-emacs-nox/leim/quail/SW.el	Wed Jul 31 13:52:10 2002
Binary files tmp-build-emacs/leim/quail/SW.elc and tmp-build-emacs-nox/leim/quail/SW.elc differ
--- tmp-build-emacs/leim/quail/TONEPY.el	Wed Jul 31 13:42:01 2002
+++ tmp-build-emacs-nox/leim/quail/TONEPY.el	Wed Jul 31 13:52:10 2002
Binary files tmp-build-emacs/leim/quail/TONEPY.elc and tmp-build-emacs-nox/leim/quail/TONEPY.elc differ
--- tmp-build-emacs/leim/quail/ZIRANMA.el	Wed Jul 31 13:42:11 2002
+++ tmp-build-emacs-nox/leim/quail/ZIRANMA.el	Wed Jul 31 13:52:19 2002
Binary files tmp-build-emacs/leim/quail/ZIRANMA.elc and tmp-build-emacs-nox/leim/quail/ZIRANMA.elc differ
--- tmp-build-emacs/leim/quail/ZOZY.el	Wed Jul 31 13:42:02 2002
+++ tmp-build-emacs-nox/leim/quail/ZOZY.el	Wed Jul 31 13:52:10 2002
Binary files tmp-build-emacs/leim/quail/ZOZY.elc and tmp-build-emacs-nox/leim/quail/ZOZY.elc differ
--- tmp-build-emacs/leim/quail/quick-b5.el	Wed Jul 31 13:42:07 2002
+++ tmp-build-emacs-nox/leim/quail/quick-b5.el	Wed Jul 31 13:52:15 2002
Binary files tmp-build-emacs/leim/quail/quick-b5.elc and tmp-build-emacs-nox/leim/quail/quick-b5.elc differ
--- tmp-build-emacs/leim/quail/quick-cns.el	Wed Jul 31 13:42:08 2002
+++ tmp-build-emacs-nox/leim/quail/quick-cns.el	Wed Jul 31 13:52:16 2002
Binary files tmp-build-emacs/leim/quail/quick-cns.elc and tmp-build-emacs-nox/leim/quail/quick-cns.elc differ
--- tmp-build-emacs/leim/quail/tsang-b5.el	Wed Jul 31 13:42:06 2002
+++ tmp-build-emacs-nox/leim/quail/tsang-b5.el	Wed Jul 31 13:52:14 2002
Binary files tmp-build-emacs/leim/quail/tsang-b5.elc and tmp-build-emacs-nox/leim/quail/tsang-b5.elc differ
--- tmp-build-emacs/leim/quail/tsang-cns.el	Wed Jul 31 13:42:07 2002
+++ tmp-build-emacs-nox/leim/quail/tsang-cns.el	Wed Jul 31 13:52:15 2002
Binary files tmp-build-emacs/leim/quail/tsang-cns.elc and tmp-build-emacs-nox/leim/quail/tsang-cns.elc differ
--- tmp-build-emacs/lib-src/fns-21.2.1.el	Wed Jul 31 13:41:56 2002
+++ tmp-build-emacs-nox/lib-src/fns-21.2.1.el	Wed Jul 31 13:52:06 2002
@@ -19,9 +19,6 @@
                ("menu-bar" buffers-menu-max-size menu-bar-help-menu menu-bar-tools-menu menu-bar-options-menu menu-bar-edit-menu menu-bar-files-menu menu-bar-file-menu nonincremental-search-forward nonincremental-search-backward nonincremental-re-search-forward nonincremental-re-search-backward nonincremental-repeat-search-forward nonincremental-repeat-search-backward nonincremental-repeat-re-search-forward nonincremental-repeat-re-search-backward menu-bar-search-menu menu-bar-adv-search-menu menu-bar-goto-menu yank-menu menu-bar-kill-ring-save clipboard-yank clipboard-kill-ring-save clipboard-kill-region menu-bar-enable-clipboard menu-bar-custom-menu menu-bar-make-toggle menu-bar-options-save send-mail-item-name read-mail-item-name menu-bar-games-menu vc-menu-map menu-bar-describe-menu menu-bar-manuals-menu kill-this-buffer kill-this-buffer-enabled-p delete-frame-enabled-p yank-menu-length menu-bar-update-yank-menu menu-bar-select-yank list-buffers-directory menu-bar-update-buffers-maxbuf menu-bar-select-buffer menu-bar-select-frame menu-bar-update-buffers-1 menu-bar-buffers-menu-list-buffers-entry menu-bar-update-buffers menu-bar-mode menu-bar-mode (provide . menu-bar))
                ("isearch" search-exit-option search-slow-window-lines search-slow-speed search-upper-case search-nonincremental-instead search-whitespace-regexp search-highlight search-invisible isearch-hide-immediately isearch-mode-hook isearch-mode-end-hook search-ring regexp-search-ring search-ring-max regexp-search-ring-max search-ring-yank-pointer regexp-search-ring-yank-pointer search-ring-update isearch-mode-map minibuffer-local-isearch-map isearch-forward isearch-regexp isearch-word isearch-cmds isearch-string isearch-message isearch-success isearch-invalid-regexp isearch-within-brackets isearch-other-end isearch-wrapped isearch-barrier isearch-just-started isearch-case-fold-search isearch-original-minibuffer-message-timeout isearch-adjusted isearch-slow-terminal-mode isearch-small-window isearch-opoint isearch-window-configuration isearch-yank-flag isearch-op-fun isearch-recursive-edit isearch-nonincremental isearch-new-forward isearch-opened-overlays isearch-input-method-function isearch-input-method-local-p isearch-mode isearch-forward isearch-forward-regexp isearch-backward isearch-backward-regexp isearch-mode-help isearch-mode isearch-update isearch-done isearch-update-ring isearch-exit isearch-edit-string isearch-nonincremental-exit-minibuffer isearch-forward-exit-minibuffer isearch-reverse-exit-minibuffer isearch-cancel isearch-abort isearch-repeat isearch-repeat-forward isearch-repeat-backward isearch-toggle-regexp isearch-toggle-case-fold isearch-delete-char isearch-yank-string isearch-yank-kill isearch-yank-x-selection isearch-mouse-2 isearch-yank-word isearch-yank-line isearch-search-and-update isearch-*-char isearch-|-char isearch-other-control-char isearch-other-meta-char isearch-quote-char isearch-return-char isearch-printing-char isearch-whitespace-chars isearch-process-search-char isearch-process-search-string isearch-ring-adjust1 isearch-ring-adjust isearch-ring-advance isearch-ring-retreat isearch-ring-advance-edit isearch-ring-retreat-edit isearch-complete1 isearch-complete isearch-complete-edit isearch-top-state isearch-pop-state isearch-push-state isearch-message isearch-message-prefix isearch-message-suffix isearch-search isearch-open-overlay-temporary isearch-open-necessary-overlays isearch-clean-overlays isearch-intersects-p isearch-close-unnecessary-overlays isearch-range-invisible isearch-overlay isearch-highlight isearch-dehighlight isearch-no-upper-case-p isearch-text-char-description isearch-unread (require . timer) isearch-lazy-highlight isearch-lazy-highlight-cleanup isearch-lazy-highlight-initial-delay isearch-lazy-highlight-interval isearch-lazy-highlight-max-at-a-time isearch isearch-lazy-highlight-face isearch-lazy-highlight-overlays isearch-lazy-highlight-wrapped isearch-lazy-highlight-start isearch-lazy-highlight-end isearch-lazy-highlight-timer isearch-lazy-highlight-last-string isearch-lazy-highlight-window isearch-lazy-highlight-window-start isearch-lazy-highlight-case-fold-search isearch-lazy-highlight-regexp isearch-lazy-highlight-cleanup isearch-lazy-highlight-new-loop isearch-lazy-highlight-search isearch-lazy-highlight-update isearch-resume)
                ("timer" timer-create timerp timer-set-time timer-set-idle-time timer-next-integral-multiple-of-time timer-relative-time timer-inc-time timer-set-time-with-usecs timer-set-function timer-activate timer-activate-when-idle disable-timeout cancel-timer cancel-function-timers timer-event-last-2 timer-event-last-1 timer-event-last timer-max-repeats timer-until timer-event-handler timeout-event-p run-at-time run-with-timer add-timeout run-with-idle-timer with-timeout-handler with-timeout y-or-n-p-with-timeout timer-duration-words timer-duration (provide . timer))
-               ("select" x-selection x-get-selection x-get-clipboard x-set-selection x-valid-simple-selection-p x-get-cut-buffer x-set-cut-buffer xselect-convert-to-string xselect-convert-to-length xselect-convert-to-targets xselect-convert-to-delete xselect-convert-to-filename xselect-convert-to-charpos xselect-convert-to-lineno xselect-convert-to-colno xselect-convert-to-os xselect-convert-to-host xselect-convert-to-user xselect-convert-to-class xselect-convert-to-name xselect-convert-to-integer xselect-convert-to-atom xselect-convert-to-identity (provide . select))
-               ("scroll-bar" (require . mouse) scroll-bar-event-ratio scroll-bar-scale scroll-bar-mode scroll-bar-mode-explicit set-scroll-bar-mode-1 set-scroll-bar-mode scroll-bar-mode scroll-bar-mode toggle-scroll-bar toggle-horizontal-scroll-bar scroll-bar-set-window-start scroll-bar-drag-position scroll-bar-maybe-set-window-start scroll-bar-drag-1 scroll-bar-drag scroll-bar-scroll-down scroll-bar-scroll-up scroll-bar-toolkit-scroll (provide . scroll-bar))
-               ("mouse" mouse-yank-at-point popup-menu mouse-major-mode-menu-prefix mouse-major-mode-menu mouse-major-mode-menu-1 mouse-popup-menubar mouse-popup-menubar-stuff mouse-minibuffer-check mouse-delete-window mouse-select-window mouse-tear-off-window mouse-delete-other-windows mouse-split-window-vertically mouse-split-window-horizontally mouse-drag-mode-line-1 mouse-drag-mode-line mouse-drag-header-line mouse-drag-vertical-line mouse-set-point mouse-last-region-beg mouse-last-region-end mouse-last-region-tick mouse-region-match mouse-set-region mouse-set-region-1 mouse-scroll-delay mouse-scroll-min-lines mouse-scroll-subr mouse-drag-overlay mouse-selection-click-count mouse-selection-click-count-buffer mouse-drag-region mouse-skip-word mouse-start-end mouse-set-mark-fast mouse-undouble-last-event mouse-region-delete-keys mouse-show-mark mouse-set-mark mouse-kill mouse-yank-at-click mouse-kill-ring-save mouse-save-then-kill-posn mouse-save-then-kill-delete-region mouse-save-then-kill mouse-secondary-overlay mouse-secondary-click-count mouse-secondary-start mouse-start-secondary mouse-set-secondary mouse-drag-secondary mouse-yank-secondary mouse-kill-secondary mouse-secondary-save-then-kill mouse-buffer-menu-maxlen mouse-buffer-menu-mode-mult mouse-buffer-menu-mode-groups mouse-buffer-menu mouse-buffer-menu-alist mouse-buffer-menu-split mouse-choose-completion font-menu-add-default x-fixed-font-alist mouse-set-font (provide . mouse) mldrag-drag-mode-line mldrag-drag-vertical-line (provide . mldrag))
                ("facemenu" (provide . facemenu) facemenu-keybindings facemenu-new-faces-at-end facemenu-unlisted-faces facemenu-face-menu facemenu-face-menu facemenu-foreground-menu facemenu-foreground-menu facemenu-background-menu facemenu-background-menu facemenu-special-menu facemenu-special-menu facemenu-justification-menu facemenu-justification-menu facemenu-indentation-menu facemenu-indentation-menu facemenu-menu facemenu-menu facemenu-keymap facemenu-keymap facemenu-add-face-function facemenu-end-add-face facemenu-remove-face-function facemenu-color-alist facemenu-update facemenu-set-face facemenu-set-foreground facemenu-set-background facemenu-set-face-from-menu facemenu-set-invisible facemenu-set-intangible facemenu-set-read-only facemenu-remove-face-props facemenu-remove-all facemenu-remove-special list-text-properties-at facemenu-read-color list-colors-display facemenu-color-equal facemenu-add-face facemenu-active-faces facemenu-get-face facemenu-add-new-face facemenu-complete-face-list facemenu-iterate)
                ("faces" (require . cus-face) face-font-selection-order face-font-family-alternatives face-font-registry-alternatives face-list make-face make-empty-face copy-face internal-find-face internal-get-face facep check-face face-id face-equal face-differs-from-default-p face-nontrivial-p face-x-resources set-face-attribute-from-resource set-face-attributes-from-resources make-face-x-resource-internal face-name face-attribute face-foreground face-background face-stipple face-background-pixmap face-underline-p face-inverse-video-p face-bold-p face-italic-p face-documentation set-face-documentation face-doc-string set-face-doc-string set-face-attribute make-face-bold make-face-unbold make-face-italic make-face-unitalic make-face-bold-italic set-face-font set-face-background set-face-foreground set-face-stipple set-face-underline set-face-underline-p set-face-inverse-video-p set-face-bold-p set-face-italic-p set-face-background-pixmap invert-face read-face-name face-valid-attribute-values face-attribute-name-alist face-descriptive-attribute-name face-read-string face-read-integer read-face-attribute read-face-font read-all-face-attributes modify-face read-face-and-attribute list-faces-sample-text list-faces-display describe-face face-attr-construct face-spec-set-match-display face-spec-choose face-spec-reset-face face-spec-set face-attr-match-p face-spec-match-p face-default-spec face-user-default-spec defined-colors x-defined-colors color-defined-p x-color-defined-p color-values x-color-values display-color-p x-display-color-p display-grayscale-p frame-background-mode frame-set-background-mode x-handle-named-frame-geometry x-handle-reverse-video x-create-frame-with-faces face-set-after-frame-default tty-handle-reverse-video tty-create-frame-with-faces tty-set-up-initial-frame-faces frame-update-faces frame-update-face-colors x-font-regexp x-font-regexp-head x-font-regexp-weight x-font-regexp-slant x-font-regexp-weight-subnum x-font-regexp-slant-subnum x-font-regexp-swidth-subnum x-font-regexp-adstyle-subnum x-resolve-font-name x-frob-font-weight x-frob-font-slant x-make-font-bold x-make-font-demibold x-make-font-unbold x-make-font-italic x-make-font-oblique x-make-font-unitalic x-make-font-bold-italic (provide . faces))
                ("cus-face" custom-facep custom-declare-face custom-face-attributes custom-face-attributes-get custom-set-faces (provide . cus-face))
diff -x Makefile.c -x config.h -x epaths.h -x *.o -x DOC-21.2.2 -x fns-21.2.2.el -x config.status -x config.log -x Makefile -x config.cache -x debian -x DEBIAN -ruN tmp-build-emacs/lisp/cus-load.el tmp-build-emacs-nox/lisp/cus-load.el
--- tmp-build-emacs/lisp/cus-load.el	Wed Jul 31 13:39:07 2002
+++ tmp-build-emacs-nox/lisp/cus-load.el	Wed Jul 31 13:49:59 2002
@@ -163,7 +163,7 @@
 (put 'reftex-making-and-inserting-labels 'custom-loads '( "reftex-vars"))
 (put 'calendar-hooks 'custom-loads '( "calendar"))
 (put 'mailalias 'custom-loads '( "mailalias"))
-(put 'frames 'custom-loads '( "desktop" "ediff-wind" "faces" "frame" "imenu" "menu-bar" "rsz-mini" "scroll-bar" "two-column"))
+(put 'frames 'custom-loads '( "desktop" "ediff-wind" "faces" "frame" "imenu" "menu-bar" "rsz-mini" "two-column"))
 (put 'gnus-server 'custom-loads '( "gnus"))
 (put 'paren-showing 'custom-loads '( "paren"))
 (put 'dos-fns 'custom-loads '( "dos-vars"))
@@ -998,8 +998,6 @@
 (custom-put-if-not 'custom-comment-face 'group-documentation nil)
 (custom-put-if-not 'custom-raised-buttons 'custom-version "21.1")
 (custom-put-if-not 'custom-raised-buttons 'standard-value t)
-(custom-put-if-not 'gnus-article-x-face-command 'custom-version "21.1")
-(custom-put-if-not 'gnus-article-x-face-command 'standard-value t)
 (custom-put-if-not 'gnus-inhibit-user-auto-expire 'custom-version "21.1")
 (custom-put-if-not 'gnus-inhibit-user-auto-expire 'standard-value t)
 (custom-put-if-not 'show-paren-ring-bell-on-mismatch 'custom-version "20.3")
Binary files tmp-build-emacs/lwlib/liblw.a and tmp-build-emacs-nox/lwlib/liblw.a differ
Binary files tmp-build-emacs/src/emacs and tmp-build-emacs-nox/src/emacs differ
Binary files tmp-build-emacs/src/emacs-21.2.1 and tmp-build-emacs-nox/src/emacs-21.2.1 differ
Binary files tmp-build-emacs/src/emacs-21.2.2 and tmp-build-emacs-nox/src/emacs-21.2.2 differ
Binary files tmp-build-emacs/src/temacs and tmp-build-emacs-nox/src/temacs differ

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Richard Stallman]

    and I'll send the patch once I've cleaned it up.  Given that patch,
    the lread.c fix,

Which lread.c fix is that?  Is it installed in the current sources?

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

Richard Stallman <rms@gnu.org> writes:

>     and I'll send the patch once I've cleaned it up.  Given that patch,
>     the lread.c fix,
>
> Which lread.c fix is that?  Is it installed in the current sources?

The one you pointed me to in the current sources.  Basically the
problem I was looking in to last week (with your help) had been, in
fact, fixed in current CVS, so I just backported the patch.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Richard Stallman]

Thanks.  I installed that same lread.c change into 21.3.

Re: Building emacs with and without X -- packaging question.

[Richard Stallman]

The difference in etc/fns-* is easy to explain.  That file is made
based on load-history, from whichever files were actually loaded.

It would take some work to be able to make the fns file invariant.
How important is it for us to do that?

I can't see an explanation for the variance in cus-load.el.
There is nothing in cus-dep.el or lisp/Makefile.in that ought
to be affected by whether Emacs is built for X.
Can you debug why it doesn't see scroll-bar.el in one case?

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

Richard Stallman <rms@gnu.org> writes:

> The difference in etc/fns-* is easy to explain.  That file is made
> based on load-history, from whichever files were actually loaded.
>
> It would take some work to be able to make the fns file invariant.
> How important is it for us to do that?

Not sure.  The original motivation was a desire to be able to
distribute emacs21 and emacs21-nox packages, and so I was trying to
figure out if I could make these packages coexist peacefully, or if
I'd need them to conflict/replace each other.  If all the files are
the same except for the executables, then there's no problem, or if
there are a few files with different names or different fs locations
that each binary knows how to find (say fns-21.2.1.el and
fns-21.2.1-nox.el), then there's no problem.  Otherwise I'll need to
make the packages conflict/replace each other, or something similar.

> I can't see an explanation for the variance in cus-load.el.
> There is nothing in cus-dep.el or lisp/Makefile.in that ought
> to be affected by whether Emacs is built for X.
> Can you debug why it doesn't see scroll-bar.el in one case?

Sure I can try.  I presume you're talking about this diff:

  -(put 'frames 'custom-loads '( "desktop" "ediff-wind" "faces" "frame" "imenu" "menu-bar" "rsz-mini" "scroll-bar" "two-column"))
  +(put 'frames 'custom-loads '( "desktop" "ediff-wind" "faces" "frame" "imenu" "menu-bar" "rsz-mini" "two-column"))

Is this one related, or likely something else?

  -(custom-put-if-not 'gnus-article-x-face-command 'custom-version "21.1")
  -(custom-put-if-not 'gnus-article-x-face-command 'standard-value t)

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Richard Stallman]

    Sure I can try.  I presume you're talking about this diff:

      -(put 'frames 'custom-loads '( "desktop" "ediff-wind" "faces" "frame" "imenu" "menu-bar" "rsz-mini" "scroll-bar" "two-column"))
      +(put 'frames 'custom-loads '( "desktop" "ediff-wind" "faces" "frame" "imenu" "menu-bar" "rsz-mini" "two-column"))

That one and the other one, both.

    Is this one related, or likely something else?

      -(custom-put-if-not 'gnus-article-x-face-command 'custom-version "21.1")
      -(custom-put-if-not 'gnus-article-x-face-command 'standard-value t)

There is no way of knowing a priori whether they are related.

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

Richard Stallman <rms@gnu.org> writes:

>     Sure I can try.  I presume you're talking about this diff:
>
>     -(put 'frames 'custom-loads '( "desktop" "ediff-wind" "faces" "frame" "imenu" "menu-bar" "rsz-mini" "scroll-bar" "two-column"))
>     +(put 'frames 'custom-loads '( "desktop" "ediff-wind" "faces" "frame" "imenu" "menu-bar" "rsz-mini" "two-column"))
>
> That one and the other one, both.
>
>     Is this one related, or likely something else?
>
>     -(custom-put-if-not 'gnus-article-x-face-command 'custom-version "21.1")
>     -(custom-put-if-not 'gnus-article-x-face-command 'standard-value t)
>
> There is no way of knowing a priori whether they are related.

I finally had time to work on this, and I think I've tracked it down.
In cus-dep.el we have:

		    (let ((expr (read (current-buffer))))
		      (condition-case nil
			  (progn
			    (eval expr)
			    (put (nth 1 expr) 'custom-autoloaded is-autoloaded)
			    (put (nth 1 expr) 'custom-where name))
			(error nil))))

Note that the condition-case ignores errors.  However, if you rewrite
the above to actually catch the signalled-condition data and print it
via message, you will find that when compiling --with-x=no, there's an
error while handling both the scroll-bar-mode and
gnus-article-x-face-command defcustoms.  In the scroll-bar-mode case
this appears to be because set-scroll-bar-mode-1 is undefined, even
though it's used as the :set value in the relevant defcustom:

  (defcustom scroll-bar-mode
    (if (eq system-type 'windows-nt) 'right 'left)
    "*Specify whether to have vertical scroll bars, and on which side.
  Possible values are nil (no scroll bars), `left' (scroll bars on left)
  and `right' (scroll bars on right).
  To set this variable in a Lisp program, use `set-scroll-bar-mode'
  to make it take real effect.
  Setting the variable with a customization buffer also takes effect."
    :type '(choice (const :tag "none (nil)")
                   (const left)
                   (const right))
    :group 'frames
    :set 'set-scroll-bar-mode-1)

The actual condition-case signalled-condition data for this error is
(void-function set-scroll-bar-mode-1), and removing the :set line from
the defcustom fixes the problem, at least to the extent that the
scroll-bar related diff in cus-dep.el goes away.  For
gnus-article-x-face-command, the condition-case signalled-condition
data is (void-variable gnus-article-compface-xbm).

If my analysis is right, is this something that should be fixed, and
if so, what would be the right way to fix it?

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> I finally had time to work on this, and I think I've tracked it down.
> In cus-dep.el we have:
>
> 		    (let ((expr (read (current-buffer))))
> 		      (condition-case nil
> 			  (progn
> 			    (eval expr)
> 			    (put (nth 1 expr) 'custom-autoloaded is-autoloaded)
> 			    (put (nth 1 expr) 'custom-where name))
> 			(error nil))))
>
> Note that the condition-case ignores errors.

With RMS's help, I've tracked down and fixed the scroll-bar.el related
diff and one other so that fns-*.el is now the only significant
difference between X and no-X versions of emacs.

Two remaining questions:

  1) would it be better if cus-dep's code didn't hide the errors while
     eval'ing the defcustoms above?  i.e. should it at least print an
     error message (or perhaps even halt)?  That would have caught
     both the defcusom errors I found (I believe the only two).

  2) to fix the problem with gnus-art.el's
     gnus-article-x-face-command, I copy-pasted the code that
     initializes gnus-article-compface-xbm from gnus-ems.el.  Can
     anyone see a problem with that as a short-term solution?  (The
     diff is below.)

Thanks

--- 0/lisp/gnus/gnus-art.el	2002-03-22 11:03:55.000000000 -0600
+++ 1/lisp/gnus/gnus-art.el	2002-09-15 16:42:46.000000000 -0500
@@ -207,7 +207,8 @@
   (if (and (fboundp 'image-type-available-p)
 	   (image-type-available-p 'xbm))
       'gnus-article-display-xface
-    (if gnus-article-compface-xbm
+    (if (eq 0 (string-match "#define"
+                            (shell-command-to-string "uncompface -X")))
 	"{ echo '/* Width=48, Height=48 */'; uncompface; } | display -"
       "{ echo '/* Width=48, Height=48 */'; uncompface; } | icontopbm | \
 display -"))

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

>   2) to fix the problem with gnus-art.el's
>      gnus-article-x-face-command, I copy-pasted the code that
>      initializes gnus-article-compface-xbm from gnus-ems.el.  Can
>      anyone see a problem with that as a short-term solution?  (The
>      diff is below.)

I've modified the diff a little to try and make it even more
defensive.  Now gnus-article-x-face-command's defcustom uses
gnus-article-compface-xbm's definition if bound, and the copy/pasted
initialization from gnus-article-compface-xbm's defvar in gnus-ems.el
otherwise.

This seems unlikely to cause serious problems, and fixes the cus-dep
failure, so unless there are objections, I'm going use this patch in
the forthcoming debian emacs21 package.

Here's the diff:

diff -ru 0/lisp/gnus/gnus-art.el 1/lisp/gnus/gnus-art.el
--- 0/lisp/gnus/gnus-art.el	2002-03-22 11:03:55.000000000 -0600
+++ 1/lisp/gnus/gnus-art.el	2002-09-15 16:42:46.000000000 -0500
@@ -207,7 +207,10 @@
   (if (and (fboundp 'image-type-available-p)
 	   (image-type-available-p 'xbm))
       'gnus-article-display-xface
-    (if gnus-article-compface-xbm
+    (if (or (and (boundp 'gnus-article-compface-xbm)
+                 gnus-article-compface-xbm)
+            (eq 0 (string-match "#define"
+                                (shell-command-to-string "uncompface -X"))))
 	"{ echo '/* Width=48, Height=48 */'; uncompface; } | display -"
       "{ echo '/* Width=48, Height=48 */'; uncompface; } | icontopbm | \
 display -"))


-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Stefan Monnier]

> The difference in etc/fns-* is easy to explain.  That file is made
> based on load-history, from whichever files were actually loaded.

Please note that in the trunk, fns-*.el is not used any more (it's still
generated only because we haven't removed all the code yet, in case we want
to revert this change).


	Stefan

Re: Building emacs with and without X -- packaging question.

[Rob Browning]

Alan Shutko <ats@acm.org> writes:

> )  But if you did two separate clean builds, the build id in the
> version would be the same and they would use the same file, and have
> problems... I think it uses offsets or something.

Do you know what constitutes a "clean build"?  I'm guessing that
anything that deletes the existing DOC-* file would cause you to get
the "same file".

If you're suggesting that I just reconfigure, then re-build without a
make clean, I'm wondering if that might be asking for trouble in the
long run, even if it works right now.  However, if that's OK, I'm
happy to proceed that direction.

Oh, and I'm also fine with just trying to handle things the way RH
handled them, but if there's some way the developers know they'd like
this "fixed", that's even better.  Off the top of my head, I wonder if
something as simple as naming the DOC file with a timestamp might be
enough -- i.e. DOC-20020610-231201 or similar.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

Re: Building emacs with and without X -- packaging question.

[Richard Stallman]

      However this
    wouldn't be safe if the files in the with and without-x install trees
    are likely to be different in important ways (i.e. different sets of
    files, binary incompatibilities in .elc files, etc.).

I don't think this changes anything but the Emacs executable, but I
cannot be sure.  It is definitely possible in principle for a .el file
to test for the presence of X at compile time.  I think that would be
an unclean method, and I think if we find such a case we should fix
it.