[XForms] Re: xforms configuration
L. D. Marks
ldm at risc4.numis.nwu.edu
Wed Sep 3 12:45:22 EDT 2003
On Wed, 3 Sep 2003, Jean-Marc Lasgouttes wrote:
> >>>>> "Angus" == Angus Leeming <angus.leeming at btopenworld.com> writes:
> Angus> Jean-Marc, Laurence Marks has been trying to compile xforms cvs
> Angus> and has made some changes, attached. Below is his summary of
> Angus> what he's done, but I think it can be simply summarised as
> Angus> Why do we ship these files in the config directory:
> Angus> config.guess config.sub depcomp libtool.m4 ltmain.sh
> Angus> They are all parts of the autoconf/libtool code. Why not allow
> Angus> the user to use the versions that come with their versions of
> Angus> the autotools?
> Because a user of xforms is not required to have any of the autotools
> installed (unless when using cvs, of course).
> I think that we have to ship all these files, except possibly
> libtools.m4. However, I think that we must sync this file with
> ltmain.sh, so even this one is needed.
> The right thing to do is to upgrade libtool files to the latest
> version (our libtool.m5 is from 2001, it seems). The choice is libtool
> 1.4.2 from october 2002 or 1.5 from last month. I do not know whether
> 1.5 can cause problems.
In the version that was in the cvs, the libtool stuff was in
acinclude.m4 so cancelled my more current version of libtool etc. I
removed it from acinclude.m4 -- you do need to ship a viable version.
> depcomp comes probably with automake, and the config.* from autoconf.
> All we have to do is upgrade from recent versions.
> Angus> 1) Removed the "on", since it does not seem to be needed.
> This is of course a solution, but how does 'on' appear on this system?
> Is this a preprocessor define in some system header? This would be
> _very_ bad...
If I remember right, "on" was defined in g++. The header was
fine with gcc, died with g++.
> Angus> 2) Removed AC_FUNC_MALLOC since it is broken on many systems.
> Fine, we probably do not need this one. But I do not think it makes
> any difference, since we do not rely anywhere on the HAVE_MALLOC
> macro. Laurence, did it really cause a problem?
Yes. If it did not find a GNU malloc it redefined it to rpl_malloc
and you then had to link this in otherwise you would have an undefined
> Angus> 3) Added in acinclude.m4 ac_save_CFLAGS=$CFLAGS At least in the
> Angus> version I was using it was not being set.
> I'll have to check this one.
> Angus> 4) Removed the libtool stuff that you had in acinclude.m4, and
> Angus> let automake/autoconf/libtool handle all this. Your version did
> Angus> not work with automake-1.7, autoconf-2.57, libtool-1.5
> I think we should just upgrade the versions we have (after making sure
> that libtool 1.5 requirements are not too high).
> Angus> 5) Added (slight overkill, but AC_PATH_XTRA does not work the
> Angus> way it claims to!) AC_SUBST(X_LIBS) AC_SUBST(X_PRE_LIBS)
> Angus> AC_SUBST(X_CFLAGS) LIBS="$X_LIBS $X_PRE_LIBS -lX11
> Angus> $X_EXTRA_LIBS $LIBS" CPPFLAGS="$X_CFLAGS $CPPFLAGS"
> Probably OK.
> Angus> 6) Added a few files needed by make dist (e.g. README, I can't
> Angus> remember them all).
> Good idea.
> Angus> 7) I also did some stuff for our own purposes, primarily
> Angus> removed pixmap.c so no extra libraries are needed and removed
> Angus> the checks for them, turned off sharing by default, restricted
> Angus> the build/dist to the library and removed some of your
> Angus> informational output at the end of the build. FYI, it works
> Angus> fine, and is setup so our code will compile forms if it does
> Angus> not find a working copy already existing on the computer.
> This should be investigated...
> Thanks for the input Laurence.
Department of Materials Science and Engineering
MSE Rm 2036 Cook Hall
2225 N Campus Drive
Evanston, IL 60201, USA
Tel: (847) 491-3996 Fax: (847) 491-7820
mailto:ldm at risc4.numis.nwu.edu
More information about the Xforms