autoconf, Visual C++ and current CVS build?

   Date: Wed, 25 Dec 2002 11:21:46 +0800
   From: Andy Dent <[email protected]>

   Am I being more than normally dumb this festive season (can't be too much
   indulgence, yet!) or is the current CVS checkin really broken?

   Non-existent files like win32/getopt.h are referenced and the new #include
   <beepcore-c/...> style hasn't been catered for in the Visual C++ projects.

(Sorry for not replying earlier; I've been really busy.)

The current CVS _is_ broken on Win32.  This is a known problem.
Looking back in my mail archive, I see that I'm holding the ball on
that one -- I said I would make the changes to the Win32 makefiles and
Huston said he would test them afterwards.  I forgot about this and
thought that we were waiting for Huston to do the work.  I'll get this
back on my inbox and do it when I have a few spare hours.  (Maybe
you'd like to help test?)

   It seems, from fringe comments, that after checking out, you have
   to run autoconf (on Unix) to put files into the correct
   directories.

This is not what I intended to do.  Instead, I imagined a batch file
to build the include directory by copying the appropriate files into
it.

   Does this mean, when you are actively developing, you are supposed
   to work against files in /usr/include?

No.

   I thought it was a big no-no to use <> inclusion for local package
   files?

Not particularly.  I've seen several projects that do this, and this
is recommended when using config.h files with autoconf.

   Why can't relative refs in "" includes be used instead?

The problem is that the include files need to work in place in the
build directory, and also when they are installed.  Since the include
files contain references to one another, either we must use the same
references in both places, or the include files must be modified prior
to being installed.  Since it's relatively easy to use the same
references, that's what we did.  There was considerable discussion
about this on the list a few months ago, and although no one was
particularly happy with this solution, I think there was agreement
that it wasn't as awful as some of the alternatives.

Anyway, as I've said before, I'm not particularly wedded to this
solution.  The best thing that can be said for it is that it is mostly
done and it seems to work.  I'm open to alternatives.

Chris


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf