11:35 p.m.
On Wed, Feb 6, 2013 at 4:29 PM, Jerry James <james(a)xemacs.org> wrote:
Does the Windows build not use ellcc? If not, then how does it build
modules?
Is it this bit in nt/xemacs.mak?
###################### Random .obj dependencies
# An explicit rule looks like this ($< works only in implicit rules):
# $(OUTDIR)\foo.obj: $(SRC)\foo.c
# $(CCV) $(TEMACS_CPP_FLAGS) $(SRC)\$((a)B).c -Fo$＠ $(BROWSERFLAGS)
$(OUTDIR)\emacs.obj: $(SRCROOT)\version.sh
$(OUTDIR)\libinterface.obj: $(SRC)\libinterface.c
$(CCV) $(TEMACS_CPP_CDECL_FLAGS) $(SRC)\$((a)B).c -Fo$＠ $(BROWSERFLAGS)
$(OUTDIR)\postgresql.obj: $(SRCROOT)\modules\postgresql\postgresql.c
$(CCV) -I$(SRC) $(TEMACS_CPP_FLAGS)
$(SRCROOT)\modules\postgresql\postgresql.c -Fo$＠ $(BROWSERFLAGS)
$(OUTDIR)\eldap.obj: $(SRCROOT)\modules\ldap\eldap.c
$(CCV) -I$(SRC) $(TEMACS_CPP_FLAGS)
$(SRCROOT)\modules\ldap\eldap.c -Fo$＠ $(BROWSERFLAGS)
If so, then it should still work, because up above, I see these:
DEFINES=$(OPT_DEFINES) \
-DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs \
-DHAVE_CONFIG_H $(PROGRAM_DEFINES) $(PATH_DEFINES)
TEMACS_CPP_FLAGS_NO_CFLAGS=-c $(CPLUSPLUS_COMPILE_FLAGS) \
$(INCLUDES) $(DEFINES) \
-DEMACS_MAJOR_VERSION=$(emacs_major_version) \
-DEMACS_MINOR_VERSION=$(emacs_minor_version) \
$(EMACS_BETA_VERSION) $(EMACS_PATCH_LEVEL) \
-DXEMACS_CODENAME=\"$(xemacs_codename:&=and)\" \
!if defined(xemacs_extra_name)
-DXEMACS_EXTRA_NAME=\""$(xemacs_extra_name:"=)"\" \
!endif
TEMACS_CPP_FLAGS=$(CFLAGS) $(TEMACS_CPP_FLAGS_NO_CFLAGS)
So the -Demacs in $(DEFINES) should end up in $TEMACS_CPP_FLAGS, which
is used to build the modules, no?
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:19 a.m.
New subject: Can't build repo tip on Cygwin
Jerry James writes:
On Wed, Feb 6, 2013 at 4:29 PM, Jerry James <james(a)xemacs.org>
wrote:
> Does the Windows build not use ellcc? If not, then how does it build modules?
Is it this bit in nt/xemacs.mak?
$(OUTDIR)\postgresql.obj: $(SRCROOT)\modules\postgresql\postgresql.c
$(CCV) -I$(SRC) $(TEMACS_CPP_FLAGS)
$(SRCROOT)\modules\postgresql\postgresql.c -Fo$＠ $(BROWSERFLAGS)
Because it only uses the normal CCV and TEMACS_CPP_FLAGS (unless -Fo
is relevant?), I suspect this does not build a module, but rather it's
the rule used when postgresql.obj is linked directly into temacs.exe.
I don't have time to look right now, but I'd start by looking for
rules for postgresql.ell and/or postgresql.dll if somebody wants to
beat me to it.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:40 a.m.
New subject: Can't build repo tip on Cygwin
Stephen J. Turnbull writes:
I don't have time to look right now, but I'd start by looking
for
rules for postgresql.ell and/or postgresql.dll if somebody wants to
beat me to it.
I don't _think_ so. The evidence from my build is that none of that
is involved, as the _only_ thing produced during the build process for
postgresql is postgresql.o . Is the whole source of the problem that
I configured --with-modules=no ? I've been doing that for years. . .
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht(a)inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:39 p.m.
New subject: Can't build repo tip on Cygwin
Henry S. Thompson writes:
I don't _think_ so. The evidence from my build is that none of
that is involved, as the _only_ thing produced during the build
process for postgresql is postgresql.o
OK, yeah, I forgot that you weren't building modules. Still, looking
for those *rules* in the Makefile might help understand what's
happening.
Is the whole source of the problem that I configured
--with-modules=no ? I've been doing that for years. . .
No, it's not the whole source. That is supposed to work (and did for
you for forever, right?), so the real source is elsewhere, a bug in
our build process or lack of support for some upgraded software.
Those Makefiles are over 10 years old, and I don't think the module
stuff got much love from Ben after originally introduced (he had no
interest in the functionality and there weren't complaints).
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:19 p.m.
New subject: Can't build repo tip on Cygwin
On Thu, Feb 7, 2013 at 2:40 AM, Henry S. Thompson <ht(a)inf.ed.ac.uk> wrote:
I don't _think_ so. The evidence from my build is that none of
that
is involved, as the _only_ thing produced during the build process for
postgresql is postgresql.o . Is the whole source of the problem that
I configured --with-modules=no ? I've been doing that for years. . .
Oh, where did I get the idea that modules were involved? Sorry about
barking up the wrong tree. Well, in that case, I still don't get what
is going on, though. Is nt/xemacs.mak the Makefile you use to build?
Because if it is, then postgresql.o is generated by this rule:
$(OUTDIR)\postgresql.obj: $(SRCROOT)\modules\postgresql\postgresql.c
$(CCV) -I$(SRC) $(TEMACS_CPP_FLAGS)
$(SRCROOT)\modules\postgresql\postgresql.c -Fo$＠ $(BROWSERFLAGS)
and TEMACS_CPP_FLAGS is set by this rule:
TEMACS_CPP_FLAGS=$(CFLAGS) $(TEMACS_CPP_FLAGS_NO_CFLAGS)
and TEMACS_CPP_FLAGS_NO_CFLAGS is set by this rule:
TEMACS_CPP_FLAGS_NO_CFLAGS=-c $(CPLUSPLUS_COMPILE_FLAGS) \
$(INCLUDES) $(DEFINES) \
-DEMACS_MAJOR_VERSION=$(emacs_major_version) \
-DEMACS_MINOR_VERSION=$(emacs_minor_version) \
$(EMACS_BETA_VERSION) $(EMACS_PATCH_LEVEL) \
-DXEMACS_CODENAME=\"$(xemacs_codename:&=and)\" \
!if defined(xemacs_extra_name)
-DXEMACS_EXTRA_NAME=\""$(xemacs_extra_name:"=)"\" \
!endif
!if defined(PATH_LATE_PACKAGE_DIRECTORIES)
-DPATH_LATE_PACKAGE_DIRECTORIES=\"$(PATH_LATE_PACKAGE_DIRECTORIES)\" \
!endif
-DEMACS_CONFIGURATION=\"$(EMACS_CONFIGURATION)\"
and DEFINES is set by this rule:
DEFINES=$(OPT_DEFINES) \
-DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs \
-DHAVE_CONFIG_H $(PROGRAM_DEFINES) $(PATH_DEFINES)
which clearly contains -Demacs. Does your Makefile come from
somewhere other than nt/xemacs.mak?
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:53 p.m.
New subject: Can't build repo tip on Cygwin
Jerry James writes:
Well, in that case, I still don't get what is going on, though.
Is
nt/xemacs.mak the Makefile you use to build?
I don't think so. I'm building using Cygwin and gcc, not
Windows-as-such and Visual Studio/C++.
So the Makefile I'm using is
modules/postgresql/Makefile
which in turn depends on
modules/postgresql/Makefile.in
which is built from
modules/postgresql/Makefile.in.in
and
modules/common/Makefile.common (which has your tiny footprints in it. . .)
In none of these do I find -Demacs, although it _is_ spread throughout
the Makefiles under src and lib-src (and nt) . . .
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht(a)inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:41 a.m.
New subject: Can't build repo tip on Cygwin
Henry S. Thompson writes:
So the Makefile I'm using is
modules/postgresql/Makefile
That's the problem, then. That Makefile doesn't know how to link
xemacs, only .ells.
This script
cd $builddir
$srcdir/configure --without-modules --with-postgresql $OTHER_OPTIONS
make distclean # or in a fresh checkout
make
should Just Work[tm] due to this definition in src/Makefile.in.in:
#if defined(HAVE_POSTGRESQL) && !defined(HAVE_SHLIB)
postgresql_objs=$(BLDMODULES)/postgresql/postgresql.o
#endif
where $(postgresql_objs) is cited in the dependencies for temacs.
What happens when you do that?
In none of these do I find -Demacs, although it _is_ spread
throughout
the Makefiles under src and lib-src (and nt) . . .
This is the magic:
MODCC=../../lib-src/ellcc
.c.o:
$(MODCC) $(MODCFLAGS) -c $<
ellcc is a special compiler control program that knows to set
-Demacs. So those Makefiles are only for building modules.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:09 p.m.
New subject: Can't build repo tip on Cygwin
Stephen J. Turnbull writes:
Henry S. Thompson writes:
> So the Makefile I'm using is
>
> modules/postgresql/Makefile
That's the problem, then. That Makefile doesn't know how to link
xemacs, only .ells.
This script
cd $builddir
$srcdir/configure --without-modules --with-postgresql $OTHER_OPTIONS
make distclean # or in a fresh checkout
make
should Just Work[tm] due to this definition in src/Makefile.in.in:
#if defined(HAVE_POSTGRESQL) && !defined(HAVE_SHLIB)
postgresql_objs=$(BLDMODULES)/postgresql/postgresql.o
#endif
I'm still worried we're at cross-purposes here. My top-level
configure is working just fine. It produces the relevant Makefile
(modules/postgresql/Makefile), and make eventually uses it:
config.status: creating modules/postgresql/Makefile.in
. . .
cd ./modules/postgresql && make all
make[1]: Entering directory `/usr/local/src/xemacs-21.5-scratch/modules/postgresql'
gcc -I../../src -I/usr/local/src/xemacs-21.5-scratch/modules/postgresql/../../src -c
postgresql.c
make[1]: Leaving directory `/usr/local/src/xemacs-21.5-scratch/modules/postgresql'
But that's clearly lost its context, as there are no flags being used
to speak of. . .
So, I try to do what you suggest above, but it can't possibly work,
because make distclean deletes all the Makefiles, so make just barfs.
> In none of these do I find -Demacs, although it _is_ spread
throughout
> the Makefiles under src and lib-src (and nt) . . .
This is the magic:
MODCC=../../lib-src/ellcc
.c.o:
$(MODCC) $(MODCFLAGS) -c $<
ellcc is a special compiler control program that knows to set
-Demacs. So those Makefiles are only for building modules.
OK, so that's the immediate problem alright --
egrep MODCC= modules/postgresql/*ake*
modules/postgresql/GNUmakefile:MODCC=gcc
modules/postgresql/Makefile:MODCC=gcc
modules/postgresql/Makefile.in:MODCC=gcc
That line comes from modules/common/Makefile.common
MODCC=＠MOD_CC＠
and that's being set to gcc because. . . we said --without-modules
So we really don't want all the ellcc palaver -- if we had it, we
wouldn't get what we need, which is just a postgresql.o compiled
correctly.
So I conclude (and this works) that what we want is the following
simple patch:
diff -r 68f8d295be49 configure.ac
--- a/configure.ac Wed Jan 23 11:48:46 2013 -0700
+++ b/configure.ac Sat Feb 09 15:04:26 2013 +0000
＠＠ -3492,7 +3492,7 ＠＠
fi
if test "$with_modules" != "yes"; then
MOD_CC="$XEMACS_CC"
- MODCFLAGS="\$(XE_CFLAGS) -I../../src -I\$(srcdir)/../../src"
+ MODCFLAGS="\$(XE_CFLAGS) -Demacs -I../../src -I\$(srcdir)/../../src"
INSTALLPATH=""
MOD_INSTALL_PROGRAM="true"
OBJECT_TO_BUILD="\$(MODNAME).o"
I suspect the following is probably wanted as well, so that all the
compile-option flags get passed down and used. . .
diff -r 68f8d295be49 Makefile.in.in
--- a/Makefile.in.in Wed Jan 23 11:48:46 2013 -0700
+++ b/Makefile.in.in Sat Feb 09 15:04:26 2013 +0000
＠＠ -77,6 +77,7 ＠＠
CFLAGS=＠CFLAGS＠
CPPFLAGS=＠CPPFLAGS＠
LDFLAGS=＠LDFLAGS＠
+XE_CFLAGS=＠XE_CFLAGS＠
## These help us choose version- and architecture-specific
directories
## to install files in.
＠＠ -320,7 +321,7 ＠＠
FRC.lisp.finder-inf.el:
${SUBDIR}: ${SUBDIR_MAKEFILES} ${GENERATED_HEADERS} FRC
- cd ./$＠ && $(MAKE) $(RECURSIVE_MAKE_ARGS) all
+ cd ./$＠ && $(MAKE) $(RECURSIVE_MAKE_ARGS)
XE_CFLAGS="$(XE_CFLAGS)" all
## This should be the same code as in configure.ac.
update-version:
But I'm hacking with incomplete understanding here, so feel free to
ignore this.
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht(a)inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:46 p.m.
New subject: Can't build repo tip on Cygwin
Henry S. Thompson writes:
> This script
>
> cd $builddir
> $srcdir/configure --without-modules --with-postgresql $OTHER_OPTIONS
> make distclean # or in a fresh checkout
> make
Oops, sorry about inverting the order of distclean and configure.
> should Just Work[tm] due to this definition in
src/Makefile.in.in:
>
> #if defined(HAVE_POSTGRESQL) && !defined(HAVE_SHLIB)
> postgresql_objs=$(BLDMODULES)/postgresql/postgresql.o
> #endif
I'm still worried we're at cross-purposes here. My top-level
configure is working just fine. It produces the relevant Makefile
(modules/postgresql/Makefile), and make eventually uses it:
config.status: creating modules/postgresql/Makefile.in
. . .
cd ./modules/postgresql && make all
I don't think this should happen, or if it does, it should be
basically irrelevant. postgresql_objs is part of objs, which is part
of link_deps, which AFAICT is a prerequisite for linking the
executable, and according to the usual .c.o rule it should be compiled
from the main build process and linked into the executable using
cppflags = $(CPPFLAGS) -Demacs -I. -I$(SRC) $(c_switch_all)
cflags = $(CFLAGS) $(cppflags)
#ifdef SOLARIS2
%.o : %.c
#else
.c.o:
#endif
$(CC) -c $(cflags) $<
*before* cd'ing to modules/postgresql and building. (This works for
me for a module that is half-baked and needs to be built into XEmacs
at present, so the #if !(HAVE_SHLIB) proprocessor control is left out
and the rule for building module's dependencies in src/Makefile.in.in
is unconditional.) If for some reason you already had a built
postgresql.o, though, that would prevent it from getting rebuilt (in
the absence of a make clean at least).
So I conclude (and this works) that what we want is the following
simple patch:
diff -r 68f8d295be49 configure.ac
--- a/configure.ac Wed Jan 23 11:48:46 2013 -0700
+++ b/configure.ac Sat Feb 09 15:04:26 2013 +0000
＠＠ -3492,7 +3492,7 ＠＠
fi
if test "$with_modules" != "yes"; then
MOD_CC="$XEMACS_CC"
- MODCFLAGS="\$(XE_CFLAGS) -I../../src -I\$(srcdir)/../../src"
+ MODCFLAGS="\$(XE_CFLAGS) -Demacs -I../../src -I\$(srcdir)/../../src"
INSTALLPATH=""
MOD_INSTALL_PROGRAM="true"
OBJECT_TO_BUILD="\$(MODNAME).o"
Looks plausible, assuming that postgresql.o is supposed to be made in
modules/postgresql rather than src. I'll try to get around to some
testing soon.
I don't have an opinion about the second part of the patch yet.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:06 a.m.
New subject: Can't build repo tip on Cygwin
Sorry to fall silent on this thread. $DAYJOB picked up steam...
On Sat, Feb 9, 2013 at 10:46 AM, Stephen J. Turnbull
<turnbull(a)sk.tsukuba.ac.jp> wrote:
I don't think this should happen, or if it does, it should be
basically irrelevant. postgresql_objs is part of objs, which is part
of link_deps, which AFAICT is a prerequisite for linking the
executable, and according to the usual .c.o rule it should be compiled
from the main build process and linked into the executable using
cppflags = $(CPPFLAGS) -Demacs -I. -I$(SRC) $(c_switch_all)
cflags = $(CFLAGS) $(cppflags)
#ifdef SOLARIS2
%.o : %.c
#else
.c.o:
#endif
$(CC) -c $(cflags) $<
*before* cd'ing to modules/postgresql and building. (This works for
me for a module that is half-baked and needs to be built into XEmacs
at present, so the #if !(HAVE_SHLIB) proprocessor control is left out
and the rule for building module's dependencies in src/Makefile.in.in
is unconditional.) If for some reason you already had a built
postgresql.o, though, that would prevent it from getting rebuilt (in
the absence of a make clean at least).
Unfortunately, this doesn't actually work. The attached patch is more
complex than Henry's, but is, I think what we really want to do, as it
will prevent further bugs of this same nature.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4084
days inactive
4097
days old
9 comments
4 participants
participants (4)
-
Henry S. Thompson -
Jerry James -
Stephen J. Turnbull -
Stephen J. Turnbull