🚀 go-pugleaf

zlsiial@cs.man.ac.uk (A. V. Le Blanc) writes:

| (1)  It should be easy to use when compiling for an already supported system.
|      There is a slight problem with the fileutils, etc., in that they are
|      awkward when, for example, include files are not in the expected
|      places, or when the C compiler requires special arguments to work
|      properly.  I have had a lot of trouble when compiling for systems whose
|      libraries contain known bugs, which I can avoid, but which the configures
|      cannot.  The gdb/binutils style is not bad here.  The patch/perl
|      style is quite good.

Do you happen to know how the patch/perl approach manages to outdo fileutils?
You're right, this is a source of problems, but I seem to recall having
similar problems configuring perl.  Does its Configure benefit from a
conceptually different approach, or does it just happen to catch more
outlying cases because it has been worked over more thoroughly?

| As someone who does a lot of GNU compilation, and who is getting into
| cross compilation gradually, I don't mind editing Makefiles, but someone
| who wants automatic configuration to take place after one or two commands
| would find this method unsatisfactory.

That's true enough.  I suppose that means that a configuration script for
groff would ultimately need to ferret out the answers to questions like

  # Uncomment the next line if you have the mmap() system call (and you
  # want to use it).
  #D4=-DHAVE_MMAP

which sounds like a job for Larry Wall's Configure.  Why do I find editing
the Makefile so much more straightforward?

	Donn Cave, University Computing Services, University of Washington
	donn@cac.washington.edu