11:01 p.m.
Hello Reviewers,
while trying to improve makefile[1] support for Windows NT native I am
faced with this problem:
ALL make rules for building XEmacs Windows NT native[2] are in
nt\xemacs.mak.
However, ＠setfilename in man\*\*.texi are obviously relative to man\*,
not nt.
Having nt\xemacs.mak to call out to man\xemacs.mak to handle the info
target (just like on Unix) would be must superior. There is no danger
in clashing with Unix makefiles since they are always called Makefile.
I would be willing to send in patches for 21.2 to make xemacs.mak
build recursively if any objections/problems can be resolved.
Any objections?
Regards,
Adrian
Footnotes:
[1] triggered by Martin's
From: Martin Buchholz <martin(a)xemacs.org>
Subject: Martin makes man & Makefile makeover
Message-ID: <14384.56980.560513.767776(a)lasker.666.com>
[2] Building in lisp, src, man, lib-src
3:46 a.m.
I say, put all the nt makefiles in the proper directories, not in nt.
Windows is not a second-class citizen w.r.t. xemacs.
Adrian Aichner wrote:
Hello Reviewers,
while trying to improve makefile[1] support for Windows NT native I am
faced with this problem:
ALL make rules for building XEmacs Windows NT native[2] are in
nt\xemacs.mak.
However, ＠setfilename in man\*\*.texi are obviously relative to man\*,
not nt.
Having nt\xemacs.mak to call out to man\xemacs.mak to handle the info
target (just like on Unix) would be must superior. There is no danger
in clashing with Unix makefiles since they are always called Makefile.
I would be willing to send in patches for 21.2 to make xemacs.mak
build recursively if any objections/problems can be resolved.
Any objections?
Regards,
Adrian
Footnotes:
[1] triggered by Martin's
> From: Martin Buchholz <martin(a)xemacs.org>
> Subject: Martin makes man & Makefile makeover
> Message-ID: <14384.56980.560513.767776(a)lasker.666.com>
[2] Building in lisp, src, man, lib-src
--
ben
--
In order to save my hands, I am cutting back on my responses, especially
to XEmacs-related mail. You
_will_ get a response, but please be patient. If you need an immediate
response and its not apparent in
your message, please say so. Thanks for your understanding.
8:43 p.m.
At 08:46 PM 11/18/99 -0700, Ben Wing wrote:
I say, put all the nt makefiles in the proper directories, not in nt.
Windows is not a second-class citizen w.r.t. xemacs.
I agree, but this is not strictly true - the windows build uses its own
private versions of some header files and source files, noteably config.h,
so it is defintely not the same as all other builds.
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
10:27 p.m.
>>>> "Andy" == Andy Piper
<andy(a)xemacs.org> writes:
Andy> At 08:46 PM 11/18/99 -0700, Ben Wing wrote: >> I say, put
Andy> all the nt makefiles in the proper directories, not in nt.
Andy> >> Windows is not a second-class citizen w.r.t. xemacs.
Andy> I agree, but this is not strictly true - the windows build
Andy> uses its own private versions of some header files and
Andy> source files, noteably config.h, so it is defintely not the
Andy> same as all other builds.
Hi Andy,
I'd say let's keep the nt subdir, but move nt\xemacs.mak to xemacs.mak
and adjust the paths for nt\config.h, etc., as required.
How about changing the name xemacs.mak to windows.mak, while we're at
it?
One concern I have with breaking nt\xemacs.mak into recursive
makefiles is this:
I wrote a lisp package called build, which parses nt\xemacs.mak and
then lets you customize-browse all the configuration variables.
The module also supports UNIX build by parsing configure.usage.
Now, parsing all the windows.mak files in various directories to come
up with all the configuration variables would be harder to do.
Cheers,
Adrian
Andy> andy
Andy> --------------------------------------------------------------
Andy> Dr Andy Piper
Andy> Senior Consultant Architect, BEA Systems Ltd
5:44 a.m.
>>>> "APA" == Adrian Aichner
<aichner(a)ecf.teradyne.com> writes:
APA> Hello Reviewers,
APA> while trying to improve makefile[1] support for Windows NT native I am
APA> faced with this problem:
APA> ALL make rules for building XEmacs Windows NT native[2] are in
APA> nt\xemacs.mak.
APA> However, ＠setfilename in man\*\*.texi are obviously relative to man\*,
APA> not nt.
man/Makefile uses makeinfo with the -o option, which explicitly
specifies the output filename. So the ＠setfilenames are ignored.
There seems to be no way to explicitly specify an output filename with
texinfmt's batch-texinfo-format, and so the ＠setfilename must be used.
But maybe that's a bug in texinfo.
An alternative is not to create files in a new directory at all.
Generate the .info files in the current directory, and then use mv to
move them to the target directory. Besides, why do we even bother
with a separate info directory? We could just create all the .info
files in man/ (where they can be used), and copied to some info
directory at `make install' time. We could also take a look at what
GNU Emacs 20.4 does.
APA> Having nt\xemacs.mak to call out to man\xemacs.mak to handle the info
APA> target (just like on Unix) would be must superior. There is no danger
APA> in clashing with Unix makefiles since they are always called Makefile.
or GNUmakefile.
APA> I would be willing to send in patches for 21.2 to make xemacs.mak
APA> build recursively if any objections/problems can be resolved.
APA> Any objections?
It seems reasonable. Check the FSF implementation first. If we can
be compatible with them easily, that would also be a win.
Martin
8949
days inactive
8952
days old
5 comments
5 participants
participants (5)
-
Adrian Aichner -
Andy Piper -
Ben Wing -
Martin Buchholz -
Paul Krause