Re: Switching to automake 1.4/autoconf 2.13

Mon, 15 Mar 1999 12:15:42 -0500 

On Mon, 15 Mar 1999 15:06:15 +0100 (MET), Jean-Marc Lasgouttes wrote:
>I finally upgraded the versions of autoconf/automake needed to build
>lyx 1.1. Every developper should do the same, as the older versions
>will not work anymore.

Hi everybody to whom it may concern,

as I remember having seen some thoughts about compatibility issues in
this context, I just thought to gather some Info lying around on my
disk (where it is of no great use for an ignorant like me, I fear) and
forward it to a place, where it might be of more use:

==================BEGIN FORWARDED MESSAGE==================
>Return-Path: <[EMAIL PROTECTED]>
>Delivered-To: [EMAIL PROTECTED]
>Date: 13 Mar 1999 20:56:31 +0900
>From: [EMAIL PROTECTED]
>Subject: Re: some OS/2 issues, was: Re: LyX 1.0.1: Typo in lib/configure.cmd
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:

>> I got confused, as there are four configure scripts, and I accidentally
>> just run the wrong one.

>> Proposal: rename files and references in the sources to
>> lib/LyX2LocConf.cmd for OS/2 and /lib/LyXLocConf for UNIX in future
>> releases?
>
>Please consult Jean-Marc for the idea.

Well, Jean-Marc, do you read this?

>> ... README.OS2 in top dir. I don't think, it will confuse there, but
>> it almost certainly won't be found in some deep subdir.
>
>Probably. ... I definitely agree that the document must be available from
>*somewhere*.


Jean-Marc, where to put the file? (If you say yes, I'll revise and mail
the whole stuff.)

...
> Nevertheless it builds very easy. And even install works, provided you
> built it with configure.cmd and make all, then edit config/makefile a
> bit and make the Makefiles. Only small and easy changes in Makefile
> required afterwards. May seem a bit complicated, but as I was not so
> sure where which stuff should be installed as what, it was of real
> value.

I agree.  In fact I did try to modify Makefiles so that they can
be used by both UNIX shells and OS/2 cmd.exe in 0.11.x days.
I could not keep pace with the change then and abandoned eventually.
You are free to do it without my approval.  The file listing of
the binary distribution may be helpful.
Now that 1.1 adopted automake, it is impossible.  Those who want
to build LyX on his/her own must build sufficiently UNIX like
environment and try to check if the macros can be expanded to useful
expressions.
BTW due to a bug in emx of
  #pragma implementation
support, the build of 1.1 cannot be automated at present.  Besides,
it crashes in the initialization of LyXGUI and all I see are beer
glasses.


===================END FORWARDED MESSAGE===================

Mime attached there is some info on the OS/2 port of autoconf, etc. and
its limitations.


Regards,
Arnd
Title: GNU Autoconf 2.13 for EMX

GNU Autoconf 2.13 for EMX

Current patchlevel: 2

Original author: Juan Jose Garcia Ripoll
Modified by Hung-Chi Chu

Table of contents

Introduction

Well I quite like OS/2 and spend much of my free time tweaking Linux programs to work with it. And sometimes I even get it!

What I've found that makes porting more difficult is sometimes building all those makefiles and configuration headers. Under Linux and most Unix like O.S. you would run a configure script that guesses most of your system peculiarities (Name of the C/C++ compiler, which headers and libraries are present, whether a function is broken...). But OS/2 is not Unix --nor even similar-- and there are enough differences to break up those configuration scripts, even if you already have a good sh-like shell.

OK, it was the state of the question until now. This port of Autoconf introduces a set of scripts and macro files able to build scripts that work well under OS/2 with EMX using all those wonderful ports of GNU utilities. But hey, that's not all. Now those scripts will work under unix as well!

How it works

Most Linux programs come with a configure script that has the purpose of guessing important system defaults. Currently, most of those scripts are built with a tool named Autoconf, from the FSF, which takes in one or two macro files (configure.in & aclocal.m4) and using the M4 macro processor and another internal set of macro files (mainly acgeneral.m4 & acspecific.m4) creates a third one, named configure. What I've done is tweaking the internal macro files, so that the code they produce is well suited to run under EMX with a filesystem that allows long file names. This release is a major rewriting of the port. The most important changes are listed in the following section.

News and changes since 2.12 port

This version is not only a patch release. All of the previously introduced changes have been arranged in a way that make them GNU compliant and unix compatible. I hope this changes to become part of a new official release of Autoconf. Help me to get it!
  • Use the new macro AC_EXEEXT introduced in 2.13 official release to determine the EXE extension. The extension value and library prefix for the current system are stored in ac_cv_exeext and ac_cv_libpre variables. You can use them in configure.in, aclocal.m4, and Makefile.
  • Find XFree86/OS2 paths by the general AC_PATH_X_XMKMF macro.
  • Add X include path to CPPFLAGS.
  • Add a rule to find shm library.
  • Remove FPATH and manipulate PATH directly (any "\" is translated to "/"). This way makes things simpler. Why do we want to use any program which can't deal with Unix path in our porting project?
  • Remove the --auxfiles option. The aux files will be replaced when running configure. The aux directory is correctly determined.
  • Remove the --clean option. You can get the same function by 'del config.cache' or 'del config.cache config.status config.log'
  • Remove AC_JOIN_PATHS and AC_LOOP_OVER_PATH since currently they are not very useful.

Requirements for running Autoconf

Here's a list of the EMX programs you'll need. Most of them are at Leo or Hobbes. And you must also be working on HPFS that allows long file names.

Installation from the pre-built package

  • Make a prefix directory for Autoconf and unpack the package there. Let's say it is e:\unix
  • Either add e:\unix\bin to PATH or move the script files autoconf, autoreconf, autoheader, autoscan, autoupdate and ifnames to some other directory which *is* listed in PATH.
  • Define the AC_MACRODIR environment variable with the path where acgeneral.m4 is. For this example, it is e:/unix/share/autoconf. You may add the following line to your config.sys: 
    	SET AC_MACRODIR=e:/unix/share/autoconf
    Beware with slashes: you must use `/', not `\'.
  • You're free to move the documentation (*.info* files) to any place which is listed in INFOPATH.
  • You'll need AWK to run Autoconf, make sure you have an executable named `gawk.exe' or set the AWK environment variable: for instance, in my system it would be 
    	set AWK=e:/usr/bin/gawk.exe

Installation from the official sources

  • Get in autoconf's directory.
  • Apply the patch for os/2. (src/diffs/autoconf*.diff)
  • Type "gmake -f Makefile.emx install prefix=%where_you_want%". Simple? :-) (See the top lines of Makefile.emx)

Using autoconf

  • Get in the directory which has the code you want to port.
  • The configure file must be already there: rename it to configure.bak.
  • Enter the unix shell. If you don't, you'll have to enclose the commands in double quoutes and prepend a `sh -c' to all of them. For example: 
    [From within CMD.EXE]
	sh -c "autoconf --help"
[From within SH.EXE]
	autoconf --help
  • Remove the cache files: 
    	del config.cache
    This should be done every time configure is rebuilt or after anything in your system changed (new programs installed, new PATH, etc) so that configure finds out those changes.
  • Build a brand new configure: 
    	autoconf
  • If you know your program is going to need some special flags, such as -Zmt, -D__ST_MT_ERRNO__, etc, then edit the lines in configure for CCFLAGS (C compiling flags), CXXFLAGS (C++ compiling flags), LDFLAGS (Flags for linking).

    Alternatively, you can export environment variables before using configure overriding the checks it could do. See Tips and Tricks for more about this.

  • Run configure with any other options you wish. Usually 
    	configure --help
    will inform you about the available options (programs to build, extensions, checks to avoid or include, etc), whereas 
    	configure --prefix=d:/usr
    will configure using default options and defining the root directory to be /usr.
  • Watch the output: if the script can't find a program, library or file you DO have; or if some strange error comes out, please e-mail me but don't abuse the author. But first have a look at Tips and Bug reports.
  • Check all the files that have been updated (configure shows their names). They're usually makefiles and a config.h. If you see a path messed (i.e. /usr/../c:/usr/bin/sh.exe) and you cannot figure out why configure failed, tell me. But please first have a look at Tips and Bug reports.
  • Now do the real port: check the code and fix it. Here I cannot help you ;)

Tips and tricks

Drive unit names and extensions

Unix programs don't know about disk units names, such as 'C:'. I've made Autoconf understand drive unit names, but this doesn't mean that your program does.

In the configuration process Autoconf may introduce absolute pathnames in the code of your program. This will typically happen, either when config.h is created, or by explicit defines when compiling. You might have to add code to let the user override these paths.

OTOH, you might find hand-made rules in aclocal.m4 or in configure.in that check whether a path reference is absolute or not. Typically it looks like in this example: 

...
case "$LD" in
  /*)	ac_program_LD="$LD";;
  *)	#some other stuff
...
This must be fixed in the following compatible mode: 
...
case "$LD" in
changequote(, )dnl
  /* | [a-zA-Z]:*) ac_program_LD="$LD";;
changequote([, ])dnl
  *)    #some other stuff
...
The fixed rule recognizes drive unit names. Also, as the colon ":" is not a valid path character under unix, it causes no big harm.

Compilation flags

Autoconf's default flags for compiling programs are, as of this release 
	CC=gcc.exe
	MAKE=make
	CXX=gcc.exe
	CPP="gcc.exe -E"
	CFLAGS="-O2 -Zmt"
	CXXFLAGS="-O2 -Zmt"
	LDFLAGS="-Zmt -Zcrtdll -Zsysv-signals -Zbin-files"
	CONFIG_SHELL=sh.exe

The flags can be overriden. Either edit the generated configure file or set environment variables 

[From within CMD.EXE]
	set MAKE=x11make.exe
	set CFLAGS=-O2
	set CFLAGS=-O2
	set LDFLAGS=-Zexe -Zcrtdll -Zsysv-signals
[From within SH.EXE]
	export MAKE=x11make.exe
	export CFLAGS=-O2
	export CFLAGS=-O2
	export LDFLAGS="-Zexe -Zcrtdll -Zsysv-signals"
or let the configure program run and, at the end, edit config.status changing the variables to suit your needs. (See below)

The default settings are good for X11 programs and won't harm when porting any other kind of application. If you opt to use them, please follow these two rules (extracted from the XFree86/OS2 porting guide):

  • You'll have problems with code declaring errno as a global variable: 
    	extern int errno;
    Autoconf-ready code shouldn't cause this problem but if it does, enclose the sentence with a #ifdef __EMX__, and make sure the program or library includes #include <errno.h>. This is a temporary solution: you should tell the author of the application about this unportable feature (we are not only speaking about OS/2) and recommend him/her to check the existence of <errno.h> with an appropiate rule.
  • Because of the -Zbin-files you'll need to introduce explicit file mode flags (O_BINARY, O_TEXT, "t", "b") in the code. If you do so, use #ifdef __EMX__ to selectively introduce the patches.

The config.status file

This script contains all of the configuration parameters and is responsible for converting the *.in files into usable ones. Some tips about this script:
  • Invoking it directly 
    [From within CMD.EXE]
	sh config.status
[From within SH.EXE]
	config.status
    will reprocess all af the *.in files. This is useful when you want to discard changes introduced in the makefiles or in config.h.
  • Instead of running configure a second time, you can edit it to change the value of any configuration parameter. For example, you could change 
    	s%@CFLAGS@%-O2 -Zmt%g
	s%@CXXFLAGS@%-O2 -Zmt%g
	s%@LDFLAGS@%-Zmt -Zcrtdll -Zsysv-signals -Zbinfiles%g
    to 
    	s%@CFLAGS@%-O2%g
	s%@CXXFLAGS@%-O2%g
	s%@LDFLAGS@%-Zexe -Zcrtdll -Zsysv-signals%g
    thus removing the already commented flags (See above).
  • You should invoke config.status whenever
    • you change any *.in file,
    • config.status changes,
    • config.status is invoked from within a makefile and causes an error: you should break the make process, invoke config.status and invoke make.exe again.

Non portable rules

There are that programs need to guess system dependent features that Autoconf currently doesn't know about. This is usually achieved with rules that are stored in aclocal.m4. Some of these rules are just a set of standard checks put together, but some other are non-portable ones (in the sense that they may not work under OS/2).

The following sections explain how rules are to be modified in order to make them OS/2 compatible. These changes are simple ones and should be notified to the maintainers together with an explanation of where to get this port of Autoconf and its compatible nature.

File names

This release introduces two variables which are used to name executable binary and library file. ac_cv_exeext is ".exe" for OS/2 and empty for Unix. ac_cv_libpre is empty for OS/2 and "lib" for Unix. Sometimes you should modify some Unix formatted filenames and add the variables.

Path separator

The path separator is stored in the PATH_IFS environment variable and is ";" under OS/2 and ":" elsewhere. You can modify configure.in or aclocal.m4 when necessary to replace the Unix path separator ":" with ${PATH_IFS}.

An example

An example shows how to modify aclocal.m4 is following: 

	[case "$LD" in
	  /*)
	  ac_cv_path_LD="$LD" # Let the user override the test with a path.
	  ;;
	  *)
	  IFS="${IFS= 	}"; ac_save_ifs="$IFS"; IFS="${IFS}:"
	  for ac_dir in $PATH; do
	    test -z "$ac_dir" && ac_dir=.
	    if test -f "$ac_dir/ld"; then
		...
	    fi
	  done
	  IFS="$ac_save_ifs"
	  ;;
	esac])
The fixed version is 
	[case "$LD" in
        changequote(, )dnl
	  /*|[a-zA-Z]:*)
        changequote([, ])dnl
	  ac_cv_path_LD="$LD" # Let the user override the test with a path.
	  ;;
	  *)
	  IFS="${IFS= 	}"; ac_save_ifs="$IFS"; IFS="${PATH_IFS}"
	  for ac_dir in $PATH; do
	    test -z "$ac_dir" && ac_dir=.
	    if test -f "$ac_dir/ld$ac_cv_exeext"; then
		...
	    fi
	  done
	  IFS="$ac_save_ifs"
          ;;
	esac])

Bug reports

If you miss a feature in autoconf, or find something doesn't work, please e-mail me.

When reporting bugs, follow these steps:

  • Make sure you have the required utilities configured and properly installed in your system.
  • If autoconf crashes, use 
    [From CMD.EXE and SH.EXE:]
	sh -x d:/usr/local/bin/autoconf 2>&1 1>error0.log
    to invoke it and e-mail me the error0.log file. Notice the use of Autoconf's full path name and the lack of the -c option.
  • If it's configure the one that fails, use 
    	autoconf --debug
    to rebuild the configure script that doesn't seem to work.
  • Run the rebuilt file with something like 
    	configure 2>&1 error.log
    and e-mail me the error.log, config.log, config.status and config.cache files. You should also send me any *.in and *.m4 files. You can pack them with ZIP archiver.
  • Be patient :)

Greetings and notes

We must thank Juan Jose Garcia Ripoll for hist GREATE port, Hung-Chi Chu

Reply via email to