"make autoloads" signals an error

"make autoloads" signals an error

[Eli Zaretskii]

Like this:

    GEN      loaddefs.el
    INFO     Scraping files for loaddefs...
    INFO     Scraping files for loaddefs...10%
    INFO     Scraping files for loaddefs...20%
    INFO     Scraping files for loaddefs...30%
    INFO     Scraping files for loaddefs...40%
    INFO     Scraping files for loaddefs...50%
    INFO     Scraping files for loaddefs...60%
    INFO     Scraping files for loaddefs...70%
    INFO     Scraping files for loaddefs...80%
    INFO     Scraping files for loaddefs...90%
    INFO     Scraping files for loaddefs...100%
    INFO     Scraping files for loaddefs...done

  Error: wrong-type-argument (integer-or-marker-p nil)
    mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode -0x2d78d25b45e2f81>))
    debug-early-backtrace()
    debug-early(error (wrong-type-argument integer-or-marker-p nil))
    loaddefs-generate(("." "./calc" "./calendar" "./cedet" "./cedet/ede" "./cedet/semantic" "./cedet/semantic/analyze" "./cedet/semantic/bovine" "./cedet/semantic/decorate" "./cedet/semantic/symref" "./cedet/semantic/wisent" "./cedet/srecode" "./emacs-lisp" "./emulation" "./erc" "./eshell" "./gnus" "./image" "./international" "./language" "./leim" "./leim/ja-dic" "./leim/quail" "./mail" "./mh-e" "./net" "./nxml" "./org" "./play" "./progmodes" "./textmodes" "./url" "./vc") "d:/gnu/git/emacs/trunk/lisp/loaddefs.el" ("d:/gnu/git/emacs/trunk/lisp/ldefs-boot.el" "d:/gnu/git/emacs/trunk/lisp/leim/leim-list.el" "d:/gnu/git/emacs/trunk/lisp/international/iso-transl.el" "d:/gnu/git/emacs/trunk/lisp/cus-start.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/eldoc.el" "d:/gnu/git/emacs/trunk/lisp/emacs-li
 sp/shorthands.el" "d:/gnu/git/emacs/trunk/lisp/paren.el" "d:/gnu/git/emacs/trunk/lisp/electric.el" "d:/gnu/git/emacs/trunk/lisp/uniquify.el" "d:/gnu/git/emacs/trunk/lisp/vc/ediff-hook.el" "d:/gnu/git/emacs/trunk/lisp/vc/vc-hooks.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/float-sup.el" "d:/gnu/git/emacs/trunk/lisp/progmodes/elisp-mode.el" "d:/gnu/git/emacs/trunk/lisp/buff-menu.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/tabulated-list.el" "d:/gnu/git/emacs/trunk/lisp/replace.el" "d:/gnu/git/emacs/trunk/lisp/newcomment.el" "d:/gnu/git/emacs/trunk/lisp/textmodes/fill.el" "d:/gnu/git/emacs/trunk/lisp/textmodes/text-mode.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/lisp-mode.el" "d:/gnu/git/emacs/trunk/lisp/progmodes/prog-mode.el" "d:/gnu/git/emacs/trunk/lisp/textmodes/paragraphs.el" "d:/gnu/
 git/emacs/trunk/lisp/register.el" "d:/gnu/git/emacs/trunk/lisp/textmodes/page.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/lisp.el" "d:/gnu/git/emacs/trunk/lisp/tab-bar.el" "d:/gnu/git/emacs/trunk/lisp/menu-bar.el" "d:/gnu/git/emacs/trunk/lisp/rfn-eshadow.el" "d:/gnu/git/emacs/trunk/lisp/isearch.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/easymenu.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/timer.el" "d:/gnu/git/emacs/trunk/lisp/select.el" "d:/gnu/git/emacs/trunk/lisp/mouse.el" "d:/gnu/git/emacs/trunk/lisp/jit-lock.el" "d:/gnu/git/emacs/trunk/lisp/font-lock.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/syntax.el" "d:/gnu/git/emacs/trunk/lisp/font-core.el" "d:/gnu/git/emacs/trunk/lisp/term/tty-colors.el" "d:/gnu/git/emacs/trunk/lisp/startup.el" "d:/gnu/git/emacs/trunk/lisp/frame.el" "d:/gnu/
 git/emacs/trunk/lisp/minibuffer.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/nadvice.el" "d:/gnu/git/emacs/trunk/lisp/simple.el" "d:/gnu/git/emacs/trunk/lisp/indent.el" "d:/gnu/git/emacs/trunk/lisp/language/indonesian.el" "d:/gnu/git/emacs/trunk/lisp/language/philippine.el" "d:/gnu/git/emacs/trunk/lisp/language/cham.el" "d:/gnu/git/emacs/trunk/lisp/language/burmese.el" "d:/gnu/git/emacs/trunk/lisp/language/khmer.el" "d:/gnu/git/emacs/trunk/lisp/language/georgian.el" "d:/gnu/git/emacs/trunk/lisp/language/utf-8-lang.el" "d:/gnu/git/emacs/trunk/lisp/language/misc-lang.el" "d:/gnu/git/emacs/trunk/lisp/language/vietnamese.el" "d:/gnu/git/emacs/trunk/lisp/language/tibetan.el" "d:/gnu/git/emacs/trunk/lisp/language/thai.el" "d:/gnu/git/emacs/trunk/lisp/language/tai-viet.el" "d:/gnu/git/emacs/trun
 k/lisp/language/lao.el" "d:/gnu/git/emacs/trunk/lisp/language/korean.el" "d:/gnu/git/emacs/trunk/lisp/language/japanese.el" "d:/gnu/git/emacs/trunk/lisp/international/eucjp-ms.el" "d:/gnu/git/emacs/trunk/lisp/international/cp51932.el" "d:/gnu/git/emacs/trunk/lisp/language/hebrew.el" "d:/gnu/git/emacs/trunk/lisp/language/greek.el" "d:/gnu/git/emacs/trunk/lisp/language/romanian.el" "d:/gnu/git/emacs/trunk/lisp/language/slovak.el" "d:/gnu/git/emacs/trunk/lisp/language/czech.el" "d:/gnu/git/emacs/trunk/lisp/language/european.el" "d:/gnu/git/emacs/trunk/lisp/language/ethiopic.el" "d:/gnu/git/emacs/trunk/lisp/language/english.el" "d:/gnu/git/emacs/trunk/lisp/language/sinhala.el" "d:/gnu/git/emacs/trunk/lisp/language/indian.el" "d:/gnu/git/emacs/trunk/lisp/language/cyrillic.el" "d:/gnu/git/emac
 s/trunk/lisp/language/chinese.el" "d:/gnu/git/emacs/trunk/lisp/composite.el" "d:/gnu/git/emacs/trunk/lisp/international/characters.el" "d:/gnu/git/emacs/trunk/lisp/international/charprop.el" "d:/gnu/git/emacs/trunk/lisp/case-table.el" "d:/gnu/git/emacs/trunk/lisp/international/mule-cmds.el" "d:/gnu/git/emacs/trunk/lisp/epa-hook.el" "d:/gnu/git/emacs/trunk/lisp/jka-cmpr-hook.el" "d:/gnu/git/emacs/trunk/lisp/help.el" "d:/gnu/git/emacs/trunk/lisp/abbrev.el" "d:/gnu/git/emacs/trunk/lisp/obarray.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/oclosure.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/cl-preloaded.el" "d:/gnu/git/emacs/trunk/lisp/button.el" "d:/gnu/git/emacs/trunk/lisp/faces.el" "d:/gnu/git/emacs/trunk/lisp/cus-face.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/macroexp.el" "d:/gnu/git/em
 acs/trunk/lisp/files.el" "d:/gnu/git/emacs/trunk/lisp/window.el" "d:/gnu/git/emacs/trunk/lisp/bindings.el" "d:/gnu/git/emacs/trunk/lisp/format.el" "d:/gnu/git/emacs/trunk/lisp/env.el" "d:/gnu/git/emacs/trunk/lisp/international/mule-conf.el" "d:/gnu/git/emacs/trunk/lisp/international/mule.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/map-ynp.el" "d:/gnu/git/emacs/trunk/lisp/custom.el" "d:/gnu/git/emacs/trunk/lisp/widget.el" "d:/gnu/git/emacs/trunk/lisp/version.el" "d:/gnu/git/emacs/trunk/lisp/keymap.el" "d:/gnu/git/emacs/trunk/lisp/subr.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/backquote.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/byte-run.el" "d:/gnu/git/emacs/trunk/lisp/emacs-lisp/debug-early.el") nil t)
    loaddefs-generate-batch()
    command-line-1(("-l" "./emacs-lisp/loaddefs-gen.elc" "-f" "loaddefs-generate-batch" "./loaddefs.el" "." "./calc" "./calendar" "./cedet" "./cedet/ede" "./cedet/semantic" "./cedet/semantic/analyze" "./cedet/semantic/bovine" "./cedet/semantic/decorate" "./cedet/semantic/symref" "./cedet/semantic/wisent" "./cedet/srecode" "./emacs-lisp" "./emulation" "./erc" "./eshell" "./gnus" "./image" "./international" "./language" "./leim" "./leim/ja-dic" "./leim/quail" "./mail" "./mh-e" "./net" "./nxml" "./org" "./play" "./progmodes" "./textmodes" "./url" "./vc"))
    command-line()
    normal-top-level()
  Wrong type argument: integer-or-marker-p, nil

Re: "make autoloads" signals an error

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>   Error: wrong-type-argument (integer-or-marker-p nil)
>     mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode -0x2d78d25b45e2f81>))
>     debug-early-backtrace()
>     debug-early(error (wrong-type-argument integer-or-marker-p nil))
>     loaddefs-generate(("." "./c

I'm unable to reproduce this -- "make autoloads" just says

  GEN      loaddefs.el
  INFO     Scraping files for loaddefs... 
  INFO     Scraping files for loaddefs...done

Does "make autoloads-force" also fail for you?  In that case, perhaps
there's a bug in the code that's computing the updates, and in that
case, it depends on which files are newer than loaddefs.el.  Hm...

Could you try removing the "c" from "elc" here:

$(lisp)/loaddefs.el: gen-lisp $(LOADDEFS)
	$(AM_V_GEN)$(emacs) \
            -l $(lisp)/emacs-lisp/loaddefs-gen.elc \
	    -f loaddefs-generate-batch $(lisp)/loaddefs.el ${SUBDIRS_ALMOST}

That should give us a more detailed backtrace.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "make autoloads" signals an error

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Jun 2022 14:26:31 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   Error: wrong-type-argument (integer-or-marker-p nil)
> >     mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode -0x2d78d25b45e2f81>))
> >     debug-early-backtrace()
> >     debug-early(error (wrong-type-argument integer-or-marker-p nil))
> >     loaddefs-generate(("." "./c
> 
> I'm unable to reproduce this -- "make autoloads" just says
> 
>   GEN      loaddefs.el
>   INFO     Scraping files for loaddefs... 
>   INFO     Scraping files for loaddefs...done

I'm guessing that's because it doesn't regenerate anything.  It fails
for me because it regenerates (a lot of) loaddefs.el, perhaps because
loaddefs-gen.el has changed recent-ish?

> Does "make autoloads-force" also fail for you?

Yes.

> In that case, perhaps there's a bug in the code that's computing the
> updates, and in that case, it depends on which files are newer than
> loaddefs.el.  Hm...
> 
> Could you try removing the "c" from "elc" here:
> 
> $(lisp)/loaddefs.el: gen-lisp $(LOADDEFS)
> 	$(AM_V_GEN)$(emacs) \
>             -l $(lisp)/emacs-lisp/loaddefs-gen.elc \
> 	    -f loaddefs-generate-batch $(lisp)/loaddefs.el ${SUBDIRS_ALMOST}
> 
> That should give us a more detailed backtrace.

Not necessary: I know where it errors out.  It's here:

                  ;; Delete the old version of the section.
                  (delete-region (match-beginning 0)
                                 (and (search-forward "\n\f\n;;;" nil t)
                                      (match-beginning 0)))

And that's because search-forward returns nil:

  Thread 1 hit Breakpoint 2, wrong_type_argument (predicate=XIL(0x8d90), value=XIL(0)) at data.c:142
  142       eassert (!TAGGEDP (value, Lisp_Type_Unused0));
  (gdb) bt
  #0  wrong_type_argument (predicate=XIL(0x8d90), value=XIL(0)) at data.c:142
  #1  0x011acd80 in fix_position (pos=XIL(0)) at buffer.c:143
  #2  0x011b4275 in validate_region (b=0x82f058, e=0x82f050) at buffer.c:2326
  #3  0x0125ba63 in Fdelete_region (start=make_fixnum(23071), end=XIL(0)) <<<<<<
      at editfns.c:2643

Re: "make autoloads" signals an error

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Not necessary: I know where it errors out.  It's here:
>
>                   ;; Delete the old version of the section.
>                   (delete-region (match-beginning 0)
>                                  (and (search-forward "\n\f\n;;;" nil t)
>                                       (match-beginning 0)))

That means that there's a loaddefs file there that's on the wrong
format.  Which ones of the loaddefs files is that?

Hm...  could this somehow be a Windows file format problem?  I'll
re-test this on Windows.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "make autoloads" signals an error

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Hm...  could this somehow be a Windows file format problem?  I'll
> re-test this on Windows.

Never mind -- it was a stupid thinko in the code.  Can you try updating
and see whether it's fixed now?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "make autoloads" signals an error

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Never mind -- it was a stupid thinko in the code.  Can you try updating
> and see whether it's fixed now?

(And you also probably need the Makefile.in change I just pushed.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "make autoloads" signals an error

[Ergus]

Maybe this is related:

Triying to build master I get this error and compilation fails since
yesterday:

   GEN      ps-print-loaddefs.el
   GEN      ibuffer-loaddefs.el
   GEN      htmlfontify-loaddefs.el
   GEN      dired-loaddefs.el

Error: file-missing ("Opening output file" "No such file or directory" "/home/ergo/gits/lisp/loaddefs.el")

This is a problem because the sources are in /home/ergo/gits/emacs, so
part of the path seems to be missing...

Any idea?
Best,
Ergus

On Wed, Jun 01, 2022 at 02:56:03PM +0200, Lars Ingebrigtsen wrote:
>Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Never mind -- it was a stupid thinko in the code.  Can you try updating
>> and see whether it's fixed now?
>
>(And you also probably need the Makefile.in change I just pushed.)
>
>-- 
>(domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no
>

Re: "make autoloads" signals an error

[Ergus]

The problem seems to be when inside the source:

mkdir build
cd build
../configure ...

When building in the path with ./configure or setting the configure with
the absolute path there is no problem.




On Wed, Jun 01, 2022 at 07:51:57PM +0200, Ergus wrote:
>Maybe this is related:
>
>Triying to build master I get this error and compilation fails since
>yesterday:
>
>  GEN      ps-print-loaddefs.el
>  GEN      ibuffer-loaddefs.el
>  GEN      htmlfontify-loaddefs.el
>  GEN      dired-loaddefs.el
>
>Error: file-missing ("Opening output file" "No such file or directory" "/home/ergo/gits/lisp/loaddefs.el")
>
>This is a problem because the sources are in /home/ergo/gits/emacs, so
>part of the path seems to be missing...
>
>Any idea?
>Best,
>Ergus
>
>On Wed, Jun 01, 2022 at 02:56:03PM +0200, Lars Ingebrigtsen wrote:
>>Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>>Never mind -- it was a stupid thinko in the code.  Can you try updating
>>>and see whether it's fixed now?
>>
>>(And you also probably need the Makefile.in change I just pushed.)
>>
>>-- 
>>(domestic pets only, the antidote for overdose, milk.)
>>  bloggy blog: http://lars.ingebrigtsen.no
>>
>

Re: "make autoloads" signals an error

[Lars Ingebrigtsen]

Ergus <spacibba@aol.com> writes:

> The problem seems to be when inside the source:
>
> mkdir build
> cd build
> ../configure ...
>
> When building in the path with ./configure or setting the configure with
> the absolute path there is no problem.

Sorry, I don't follow.  What's the recipe to reproduce the problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "make autoloads" signals an error

[Yuri D'Elia]

On Thu, Jun 02 2022, Lars Ingebrigtsen wrote:
> Ergus <spacibba@aol.com> writes:
>
>> The problem seems to be when inside the source:
>>
>> mkdir build
>> cd build
>> ../configure ...
>>
>> When building in the path with ./configure or setting the configure with
>> the absolute path there is no problem.
>
> Sorry, I don't follow.  What's the recipe to reproduce the problem?

I'm also experiencing this on a fresh checkout.

This happens when building emacs off-tree (which didn't seem to work to
well in the past.. but I consider good practice anyway..)

The instructions are clear: make a subdirectory inside the source tree,
then "configure" and make inside it exactly as he described. From a
checked-out tree:

  mkdir build
  cd build
  ../configure
  make

Re: "make autoloads" signals an error

[Lars Ingebrigtsen]

Yuri D'Elia <wavexx@thregr.org> writes:

> The instructions are clear: make a subdirectory inside the source tree,
> then "configure" and make inside it exactly as he described. From a
> checked-out tree:
>
>   mkdir build
>   cd build
>   ../configure
>   make

If I try that, it bugs out with:

...
  CC       doc.o
  CCLD     temacs
/usr/bin/ld: cannot find dispnew.o: No such file or directory
/usr/bin/ld: cannot find frame.o: No such file or directory
[etc]

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "make autoloads" signals an error

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> The instructions are clear: make a subdirectory inside the source tree,
>> then "configure" and make inside it exactly as he described. From a
>> checked-out tree:
>>
>>   mkdir build
>>   cd build
>>   ../configure
>>   make
>
> If I try that, it bugs out with:
>
> ...
>   CC       doc.o
>   CCLD     temacs
> /usr/bin/ld: cannot find dispnew.o: No such file or directory
> /usr/bin/ld: cannot find frame.o: No such file or directory
> [etc]

Ah, it has to be a tree that hasn't already been built for it to work.
That is, a fresh checkout, and then ./autogen.sh in the directory, and
then the steps above.  And with that I can reproduce the problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "make autoloads" signals an error

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 02 Jun 2022 12:08:19 +0200
> 
> Yuri D'Elia <wavexx@thregr.org> writes:
> 
> > The instructions are clear: make a subdirectory inside the source tree,
> > then "configure" and make inside it exactly as he described. From a
> > checked-out tree:
> >
> >   mkdir build
> >   cd build
> >   ../configure
> >   make
> 
> If I try that, it bugs out with:
> 
> ...
>   CC       doc.o
>   CCLD     temacs
> /usr/bin/ld: cannot find dispnew.o: No such file or directory
> /usr/bin/ld: cannot find frame.o: No such file or directory
> [etc]

I think you didn't clean your tree?

Re: "make autoloads" signals an error

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think you didn't clean your tree?

Wasn't part of the recipe.  :-/

Anyway, I'm testing the same in Emacs 28 just to see how it's supposed
to work -- and is an out-of-build tree supposed to write the .elc files
in the tree?  I.e., build/lisp/ remains empty after finishing the build?

(Except for a Makefile.)

The problem seems to be that loaddefs-gen tries to put the generated
files into build/lisp/, and then Emacs can't find them.  So I'll adjust
that to put them into lisp-directory instead.  But isn't this a bug?
That is, an out-of-tree build shouldn't alter the source tree at all I'd
have thought?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "make autoloads" signals an error

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: wavexx@thregr.org,  emacs-devel@gnu.org
> Date: Thu, 02 Jun 2022 13:20:03 +0200
> 
> Anyway, I'm testing the same in Emacs 28 just to see how it's supposed
> to work -- and is an out-of-build tree supposed to write the .elc files
> in the tree?  I.e., build/lisp/ remains empty after finishing the build?
> 
> (Except for a Makefile.)
> 
> The problem seems to be that loaddefs-gen tries to put the generated
> files into build/lisp/, and then Emacs can't find them.  So I'll adjust
> that to put them into lisp-directory instead.  But isn't this a bug?
> That is, an out-of-tree build shouldn't alter the source tree at all I'd
> have thought?

Ideally, it shouldn't modify the source tree, but:

  . if you build a release tarball, the *.elc files are already there
    in the source tree;
  . the *.elc files are platform-independent, so there shouldn't be a
    need to regenerate them for every build;
  . if you put the *.elc files in the build tree, you need to adjust
    load-path, since some of the files (the ones we don't
    byte-compile) will be in the source tree, and others in the build
    tree

So the reason(s) to make changes here are weak enough for us to punt ;-)

Re: "make autoloads" signals an error

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Ideally, it shouldn't modify the source tree, but:
>
>   . if you build a release tarball, the *.elc files are already there
>     in the source tree;
>   . the *.elc files are platform-independent, so there shouldn't be a
>     need to regenerate them for every build;

Yes, that's a very good point.

>   . if you put the *.elc files in the build tree, you need to adjust
>     load-path, since some of the files (the ones we don't
>     byte-compile) will be in the source tree, and others in the build
>     tree

Hm, yes.  But...  would just prepending the build/lisp/* directories to
load-path fix that issue?  I.e., use the .elc files from build/lisp and
fall back on lisp-directory otherwise?

> So the reason(s) to make changes here are weak enough for us to punt ;-)

Yeah, I guess there isn't really much to be gained except a certain
sense of purity.  Or...  well, users would then not have to remember to
do a "make extraclean" or whatever to do a completely fresh build --
they'd just have to nuke the build directory and create a new one.
Perhaps it might be worth offering that as an option?  But perhaps not
worth the work involved.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "make autoloads" signals an error

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: wavexx@thregr.org,  emacs-devel@gnu.org
> Date: Thu, 02 Jun 2022 13:59:40 +0200
> 
> >   . if you put the *.elc files in the build tree, you need to adjust
> >     load-path, since some of the files (the ones we don't
> >     byte-compile) will be in the source tree, and others in the build
> >     tree
> 
> Hm, yes.  But...  would just prepending the build/lisp/* directories to
> load-path fix that issue?  I.e., use the .elc files from build/lisp and
> fall back on lisp-directory otherwise?

How do you prepend it?  The setting of load-path is done early during
startup, see init_lread.

Re: "make autoloads" signals an error

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Hm, yes.  But...  would just prepending the build/lisp/* directories to
>> load-path fix that issue?  I.e., use the .elc files from build/lisp and
>> fall back on lisp-directory otherwise?
>
> How do you prepend it?  The setting of load-path is done early during
> startup, see init_lread.

We'd have to add some facility to Emacs to do so (perhaps via a new
command line option).  As I said, I'm not sure this is worth doing at
all -- but if somebody does this, it doesn't sound like it's a major
practical problem to make this work.

Probably.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "make autoloads" signals an error

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: wavexx@thregr.org,  emacs-devel@gnu.org
> Date: Fri, 03 Jun 2022 05:13:04 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Hm, yes.  But...  would just prepending the build/lisp/* directories to
> >> load-path fix that issue?  I.e., use the .elc files from build/lisp and
> >> fall back on lisp-directory otherwise?
> >
> > How do you prepend it?  The setting of load-path is done early during
> > startup, see init_lread.
> 
> We'd have to add some facility to Emacs to do so (perhaps via a new
> command line option).

My point was to say it wouldn't be trivial.

> As I said, I'm not sure this is worth doing at all -- but if
> somebody does this, it doesn't sound like it's a major practical
> problem to make this work.
> 
> Probably.

I can go with "probably" ;-)

Re: "make autoloads" signals an error

[Andreas Schwab]

On Jun 02 2022, Lars Ingebrigtsen wrote:

> Hm, yes.  But...  would just prepending the build/lisp/* directories to
> load-path fix that issue?  I.e., use the .elc files from build/lisp and
> fall back on lisp-directory otherwise?

You will also have to adjust the install-arch-indep target.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: "make autoloads" signals an error

[Lars Ingebrigtsen]

Ergus <spacibba@aol.com> writes:

> The problem seems to be when inside the source:
>
> mkdir build
> cd build
> ../configure ...
>
> When building in the path with ./configure or setting the configure with
> the absolute path there is no problem.

This should now be fixed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "make autoloads" signals an error

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Jun 2022 14:50:57 +0200
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Hm...  could this somehow be a Windows file format problem?  I'll
> > re-test this on Windows.
> 
> Never mind -- it was a stupid thinko in the code.  Can you try updating
> and see whether it's fixed now?

Yes, fixed.  Thanks.