Re: autoconf, Visual C++ and current CVS build?

At 11:54 PM -0500 24/12/02, Chris Hanson wrote:
>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 thought so - I was just being polite :-)

I don't think it's just a case of editing projects - there seemed to be
files like getopt.h missing.
(referenced from beepd.c and beepng.c)

As an experienced (aka singed) CVS user I'm wondering if, when refactoring
the repository, you've missed adding back some files which are still on
your local disk, hence *you* can compile.

Has anyone compiled after a totally clean checkout?
(This used to be a regular morning step at my last job, in a very XP
environment - not so trivial with remote servers!)

If all the files are provided, I think I have working Visual C++ projects.
I've just sidelined that stuff whilst I finish the pure XML BEEPX C++
version (have rough Python test environment going).

>(Maybe you'd like to help test?)
sure

>   Does this mean, when you are actively developing, you are supposed
>   to work against files in /usr/include?
>
>No.
In that case I'm still confused.

When you check out from CVS, it seems from your response that there's a
batch process to run which puts files in /usr/include.

The file references are based around <beepcore-c/something> so how do you
have a working area?

Does this rely on NOT having them installed if you have a working area, and
resolving the <beepcore-c/...> refs via an -I directive?

>   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.

I still don't quite get this.

I'm used to writing makefiles like

CTREE_ROOT = /Users/andydent/dev/faircom_711/MacOSX
CTREE_INCLUDES = -I${CTREE_ROOT}/ctree/include -I${CTREE_ROOT}/ctree/custom
CC3 = -I${INC} ${CTREE_INCLUDES} ${COPTS} ${DEFS}
...
ooflist.o: ${CORE}ooflist.cpp ${INC}ooflist.h
	${CC} ${CORE}ooflist.cpp ${CC3}


none of my files have any explicit directory references or subdir
references - that way I've been able to ship software used on Mac, Windows
and at least half a dozen different Unix variants all over the world for
several years (see, I'm not as naive as my questions might sound :-).

I learned how to write makefiles at least 15 years ago - I'm not up on all
this newfangled 'configure' stuff!


>The best thing that can be said for it is that it is mostly
>done and it seems to work.

It seems to work on Unix makefiles given the checkout process you guys have
in place (I've not verified that - I'm assuming it from comments read).

It hasn't been demonstrated to be easy to make work with Windows projects
nor with anything else (we're building with CodeWarrior as well on Mac and
Palm).

Windows and Mac users (pre OS/X) aren't used to putting header files under
a /usr/include style root but keeping them together with the development
packages. People on OS/X are still coming to terms with some of the Unix
idioms.

I'm not trying to be awkward, honest, and if I can put together some
clearer instructions to get people started using the project I'm also quite
happy to contribute those back. I'm being pushy because I'm trying to write
those instructions.
-- 

Andy Dent BSc  MACS  AACM   http://www.oofile.com.au/
OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
PP2MFC - PowerPlant->MFC portability


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