At 11:49 27/04/01 +0200, you wrote:
>On Friday, 27. April 2001 06:19, Shlomi Fish wrote:
> > The autoconf/automake/libtool - enabled version of Freecell Solver is now
> > available for download from the Freecell Solver site. It seems to work and
> > to build a shared library (DLL for you Windows Folks), a static library
> > and an fc-solve program that links against the shared library.
> >
> > There are some known issues in it:
> >
> > 1. Autoconf throws a lot of definitions to the compiler's command-line.
> > They don't disturb the build process, but they are not necessary either.
>Try AM_CONFIG_HEADER(config.h) or pick another name for it as it may clash
>with the config.h you have.
Yes, that sound like a good idea. It will be done.
> >
> > 2. All those arguments are passed to the board_gen programs, which do not
> > require them, as they are separate programs from fc-solve.
>That's the way it wokrs.
Is there any way I can distinct the build process of the board_gen programs
from the main building process. They still compile as they are now, but I'd
rather they compile with plain "gcc -O3 -o myprog myprog.c".
> >
> > 3. config.h is not generated using autoconf's macros, but rather is
> > produced by a dedicated shell script code. Since it contains non-standard
> > #define's, I think it is OK to do it, but maybe it is possible to write a
> > good enough config.h.in.
>Write a config.h.bot and put your stuff in there, it will be attached as it
>is to the produced config.h
Is config.h.bot a shell script? If so does it accepts the shell variables
that I use in the main script (which control its content) or do I need to
make them into environment variables?
Autoconf is complicated.
> >
> > One thing I noticed is that using those three tools more than doubled the
> > size of the archive - from 105,471 bytes to 260,491 bytes. I was planning
> > to celebrate the occasion when Freecell Solver would pass the 128KB
> > barrier, but now it seems that I will soon celebrate the 256KB one. :-)
> > But, having read "Porting UNIX Software", I know that this space is a
> > small price to pay for portability.
>They so so, yes :)
Indeed. I know that on some version of IRIX, the default make does not know
how to handle either the $< or the $_at_ variables. And the problem is that we
don't have GNU make around those workstatations and we don't have enough
quota to compile it. Well, at least SGI are switching to Linux, or so is
the word on the street.
> >
> > Learning to use those tools was mostly done from the GNU info pages and
> > from the configuration files of other programs I downloaded. The AC/AM/LT
> > book, which I downloaded, was not very helpful. Maybe it was because I was
> > anxious to get a working version, and did not have the patience to read
> > the book from the beginning to the end. Some say that the lazy man works
> > twice, but I think my way was faster.
> >
> > The incenitive behind the switch to AC/AM/LT was that I could build FCS as
> > a shared library. If Freecell Solver is going to be used by kpat (that is
> > a present fact), by PySol (Markus?), and by GNOME AisleRiot (for now it
> > seems I'll have to do that one myself sometime), then it makes sense it
> > would be a separate package, which will contain the library and the
> > command-line tool.
>But then it should be more flexible. Currently the kpat's config.h is patched
>to accept two decks and longer stacks to make my version of 'kings' solvable.
Did you place this patch in the CVS?
>Greetings, Stephan
>
>--
>People in cars cause accidents. Accidents in cars cause people.
Speaking of autoconf, there seems to be a meta-project going on called the
Software Carpentry project which aims to create a better replacement for
make autoconf, the various testing framework tools, and the bug tracking
tools.
Its URL is:
http://software-carpentry.codesourcery.com/
It insists that everything will be in Python, but it may have the right
wave I think. Autoconf is one patchy hack over another, and I think one can
come up with a better tool, assuming you depend on python or something like
that. As for make: I kinda like it, but even GNU make, which I believe is
the most powerful make out there, gives me problems, and is far from being
Church-Rosser complete. But it will take some time until this project or a
similar one will become commonplace, and until then AC/AM/LT is the way to go.
BTW, the Software Carpentry has the following quote on this page:
"
Nine years ago, when I first release Python to the world, I distributed it
with a Makefile for BSD Unix. The most frequent questions and suggestions I
received in response to these early distributions were about building it on
different Unix platforms. Someone pointed me to autoconf, which allowed me
to create a configure script that figured out platform idiosyncracies
Unfortunately, autoconf is painful to use -- its grouping, quoting and
commenting conventions don't match those of the target language, which
makes scripts hard to write and even harder to debug. I hope that this
competition comes up with a better solution --- it would make porting
Python to new platforms a lot easier!
--- Guido van Rossum, Technical Director, Python
Consortium
"
Now, if we need a tool written in python to build python, then we have a
bootstrapping issue on our hands. Ho! The wonders of cross-compiling...
Regards,
Shlomi Fish
>To unsubscribe from this group, send an email to:
>fc-solve-discuss-unsubscribe_at_yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
----------------------------------------------------------------------
Shlomi Fish shlomif_at_techie.com
Home Page:
http://t2.technion.ac.il/~shlomif/
I don't believe in fairies. Oops! A fairy died.
I don't believe in fairies. Oops! Another fairy died.
Received on Fri Apr 27 2001 - 07:11:49 IDT