Re: master 32fe187bdf1: Install rcs2log within Emacs packages for Android

Re: master 32fe187bdf1: Install rcs2log within Emacs packages for Android

[Eli Zaretskii]

>     * src/callproc.c (syms_of_callproc) <Vrcs2log_program_name>: New
>     defvar.  Define to `librcs2log.so' under Android, `rcs2log'

Why do we need this variable defined and initialized in C?  Can't we
do that in Lisp instead?  Since vc-rcs.el needs it, can't the variable
be defined there, for example?

Re: master 32fe187bdf1: Install rcs2log within Emacs packages for Android

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>>     * src/callproc.c (syms_of_callproc) <Vrcs2log_program_name>: New
>>     defvar.  Define to `librcs2log.so' under Android, `rcs2log'
>
> Why do we need this variable defined and initialized in C?  Can't we
> do that in Lisp instead?  Since vc-rcs.el needs it, can't the variable
> be defined there, for example?

We do this for consistency with the other -program-name variables for
programs within exec-directory.  Moreover, Lisp other than vc-rcs.el may
want to use rcs2log: it helps to have its name defined in a central
location, instead of forcing everyone to either require vc or duplicate
the definition within syms_of_callproc.

Re: master 32fe187bdf1: Install rcs2log within Emacs packages for Android

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 24 Aug 2023 16:42:44 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >>     * src/callproc.c (syms_of_callproc) <Vrcs2log_program_name>: New
> >>     defvar.  Define to `librcs2log.so' under Android, `rcs2log'
> >
> > Why do we need this variable defined and initialized in C?  Can't we
> > do that in Lisp instead?  Since vc-rcs.el needs it, can't the variable
> > be defined there, for example?
> 
> We do this for consistency with the other -program-name variables for
> programs within exec-directory.

Those other variables should be moved out of there as well, IMO.  They
are recent additions, AFAIU as part of the Android merge.  I see no
reason to have them defined in C, as they are not invoked from any C
code, are they?

> Moreover, Lisp other than vc-rcs.el may want to use rcs2log: it
> helps to have its name defined in a central location, instead of
> forcing everyone to either require vc or duplicate the definition
> within syms_of_callproc.

OK, then let's have them in simple.el or in files.el.  Or any other
preloaded Lisp, if those two don't sound appropriate.

Re: master 32fe187bdf1: Install rcs2log within Emacs packages for Android

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> OK, then let's have them in simple.el or in files.el.  Or any other
> preloaded Lisp, if those two don't sound appropriate.

files.el or simple.el don't have access to the mailutils or
ANDROID_STUBIFY defines in config.h.

Re: master 32fe187bdf1: Install rcs2log within Emacs packages for Android

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 24 Aug 2023 17:30:09 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > OK, then let's have them in simple.el or in files.el.  Or any other
> > preloaded Lisp, if those two don't sound appropriate.
> 
> files.el or simple.el don't have access to the mailutils or
> ANDROID_STUBIFY defines in config.h.

What is the significance of ANDROID_STUBIFY for these variables?
Cannot the proper values be determined in Lisp using some other
evidence or variable?

Re: master 32fe187bdf1: Install rcs2log within Emacs packages for Android

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> What is the significance of ANDROID_STUBIFY for these variables?

ANDROID_STUBIFY is t when portions of the Android port code are compiled
to run on the build machine (for compiling Lisp and generating the Org
manuals), while the Mailutils defines are non-nil when Emacs isn't
distributed with its own movemail.

> Cannot the proper values be determined in Lisp using some other
> evidence or variable?

Not by any means I know of -- and I'm averse to introduce two more
DEFSYM and feature variables for this purpose.  Besides, what's the
purpose of moving them to Lisp?  We also define shell-file-name,
exec-suffixes, exec-directory, data-directory, doc-directory, and even
configure-info-directory within callproc.c, which is the natural
location for such things.

Re: master 32fe187bdf1: Install rcs2log within Emacs packages for Android

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 24 Aug 2023 18:11:23 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What is the significance of ANDROID_STUBIFY for these variables?
> 
> ANDROID_STUBIFY is t when portions of the Android port code are compiled
> to run on the build machine (for compiling Lisp and generating the Org
> manuals), while the Mailutils defines are non-nil when Emacs isn't
> distributed with its own movemail.
> 
> > Cannot the proper values be determined in Lisp using some other
> > evidence or variable?
> 
> Not by any means I know of -- and I'm averse to introduce two more
> DEFSYM and feature variables for this purpose.

Why isn't system-type or something similar enough for that?

And if that's not good enough, I think we should have a Lisp variable
or function to do this job, because these issues will keep popping up,
and doing all of that in C, just because we don't have the information
in Lisp, is not a good idea.  We do stuff like that in other cases,
cf.  noninteractive, window-system, daemonp, etc.

> Besides, what's the purpose of moving them to Lisp?

First, it's cleaner.  And second, these issues will happen in Lisp
code as well, and inventing a primitive for each one of them is not
the best idea.

> We also define shell-file-name, exec-suffixes, exec-directory,
> data-directory, doc-directory, and even configure-info-directory
> within callproc.c, which is the natural location for such things.

I don't see how these are relevant.  These variables are actually used
in callproc.c, with the single exception of configure-info-directory.

Re: master 32fe187bdf1: Install rcs2log within Emacs packages for Android

[Andreas Schwab]

On Aug 24 2023, Eli Zaretskii wrote:

> And if that's not good enough, I think we should have a Lisp variable
> or function to do this job, because these issues will keep popping up,
> and doing all of that in C, just because we don't have the information
> in Lisp, is not a good idea.  We do stuff like that in other cases,
> cf.  noninteractive, window-system, daemonp, etc.

Or add a feature for it.

-- 
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: master 32fe187bdf1: Install rcs2log within Emacs packages for Android

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Po Lu <luangruo@yahoo.com>,  emacs-devel@gnu.org
> Date: Thu, 24 Aug 2023 12:51:52 +0200
> 
> On Aug 24 2023, Eli Zaretskii wrote:
> 
> > And if that's not good enough, I think we should have a Lisp variable
> > or function to do this job, because these issues will keep popping up,
> > and doing all of that in C, just because we don't have the information
> > in Lisp, is not a good idea.  We do stuff like that in other cases,
> > cf.  noninteractive, window-system, daemonp, etc.
> 
> Or add a feature for it.

Yes, that'd be also good.

Re: master 32fe187bdf1: Install rcs2log within Emacs packages for Android

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Why isn't system-type or something similar enough for that?

Because that says nothing about Mailutils.

> And if that's not good enough, I think we should have a Lisp variable
> or function to do this job, because these issues will keep popping up,
> and doing all of that in C, just because we don't have the information
> in Lisp, is not a good idea.  We do stuff like that in other cases,
> cf.  noninteractive, window-system, daemonp, etc.

But it's cleaner to have them in C.  It will consume less space in the
dump image, less Lisp will require revisions upon changes to the C build
system, and so on.

> First, it's cleaner.

How is it more elegant to incessantly pawn issues off into Lisp?

> And second, these issues will happen in Lisp code as well, and
> inventing a primitive for each one of them is not the best idea.

I must disagree: the only bearing such build details have upon process
execution is the name of the executables within exec-directory.  Other
details can be adequately addressed through examining the values of
`system-type' and the feature list.

> I don't see how these are relevant.  These variables are actually used
> in callproc.c, with the single exception of configure-info-directory.

And also Vshell_file_name.  callproc.c's sole job is to set it, based on
build and system information.