uisp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Uisp-dev] building uisp on OS X


From: Theodore A. Roth
Subject: Re: [Uisp-dev] building uisp on OS X
Date: Fri, 22 Nov 2002 10:57:57 -0800 (PST)

Hi Jake,

On Fri, 22 Nov 2002, Jake McGuire wrote:

:) ( i hope this isn't a double-post )
:)
:) I'm trying to build uisp on OS X (planning to run on a PowerBook using
:) an USB->RS-232 dongle).
:)
:) I ran into a couple of issues:
:)
:) bootstrap: wants exactly automake version 1.4 and autoconf version 2.13.
:) I have automake 1.6 and autoconf 2.5 - modifying the checks in boostrap
:) so that they accept my versions didn't create any obvious difficulties.
:) I could install back-level tools, but is there any reason these checks
:) can't be made a bit more lenient?

You only need those tools if you are working with the source from cvs or
changing the configure.in and Makefile.am files. For a release tarball,
they are not needed to build the source. [sorry if I'm telling you
something you already know]

We force the use of specific versions of the tools because there are
problems using the input files with newer versions of the files (from what
I've heard and seen in my attempts to use the newer tools). By forcing
specific versions, every developer is gauranteed the same results. If
someone where to make changes to configure.in using the newer tools, it
might not work when I try to apply the patch and review it.

:)
:) src/DAPA.C:  the logic around NO_DIRECT_IO is a bit backwards.  If you
:) use -DNO_DIRECT_IO, the macros ioport_* are not defined.

That might have been done that way purposely. I don't know. After
pondering this a bit I think your patch is valid though. On OS X, you
don't even have a parallel port, so DAPA.C is moot anyways, and we should
not break the build.

:)
:) src/DAPA.C: the macro par_release sometimes gets defined to (0).  This
:) generates a warning for "statement has no effect" which is treated as an
:) error because the par_release is called without looking at the return
:) value.  If the return value of par_release is not going to be checked,
:) it should probably be defined to nothing.

Sounds valid.

:)
:) proposed DAPA.C diffs:
:)

Committed.

Ted Roth





reply via email to

[Prev in Thread] Current Thread [Next in Thread]