Hi,

I've posted an earlier post in both these groups on questions about make.
This was because I was having doubts which approach to use and I had trouble
implementing the possible approaches.

After quite some time of debugging the make file I have finally figured out
what the problem is. I read somewhere that if make doesn't work as
expected, it is usually the Makefile that is wrong, not make. I think I may
have found the exception to this rule, because my Makefile is working fine
on a BSD environment, but not in DOS/Windows.

This is due to the way that make handles directory names, particularly the
slashes within those directory names. On DOS variables set by make (such as
CURDIR) have forward slashes, while variables set by the user in the
Makefile _require_ back slashes. This is especially essential for the VPATH
variable. Another thing: unlike what the documentation states (use ; to
seperate on DOS systems) multiple directories in the VPATH variable have to
be seperated by spaces (and maybe colons too, I haven't tested that yet).

I am using make 3.79.1 that came with MinGW so maybe these errors are
specific to this version and getting a different/newer version, the problems
will be fixed.

--
Martijn
http://www.sereneconcepts.nl

"Martijn" <subscription-NOSPAM-101@hotNOFILTERmail.com> wrote in message
news:3f465c3f$0$49109$e4fe514c@news.xs4all.nl...
You may want to subscribe to the gnu make mailing list and post there:
help-make@gnu.org

More info at: http://www.gnu.org/software/make/make.html

-Wm

"Martijn" <subscription-NOSPAM-101@hotNOFILTERmail.com> writes:

I've been following your threads, and as far as I recall,
this is the first mention you've made that you would like
your makefiles to work on DOS/WIN32 as well as unix.

I would advise you not to try to make the same makefile
serve for both unix and windows. It will be easier to
maintain separate makefile.unix and makefile.win32.

-SEan

Sean Burke wrote:
I did mention it in one of my previous posts ("Re: make religion", aug. 20,
19:45), but I really wanted, as you correctly derived, to create a
cross-platform makefile.

The problem is that they contain pretty much the same. Of course this is
now still true, except for the orientation of some slashes

Thanks for the layout presented in the other thread, really gave me some
more ideas.

--
Martijn
http://www.sereneconcepts.nl

Martijn wrote:
I've been using the same Makefile on Windows and Unix (linux and
solaris) using gnumake and cygwin without a problem for a number of years.

There are sometimes a few differences which are easily managed using
conditional includes.

So what seems to be the problem ?

Gianni Mariani wrote:
My thoughts exactly - so have I, but this is the first time I have been
using VPATH (and I use MinGW i.s.o. CygWin).

Well, even after upgrading to the new version of make provided by MinGW
(3.80-3 which is somehow 5 times as big as 3.79.1 - is this bloat normal?) I
still experience the same problems. I haven't tried compiling the original
make provided by GNU yet (it either requires MSVC or DJGPP).

Anyway, it comes down to this: the first one _doesn't_ work on Windows (but
it freaks out BSD as expected), while the second one _does_, but has the
problem that internal variables use forward slashes but VPATH (and mkdir
too, btw, but that's expected) requires backslashes.

(I hope I didn't make any mistakes in trimming it down)

--------------------------------------------------------------
Makefile.1

SHELL = /bin/sh

OUTPREFIX = ../build/
SRCPREFIX := ../../../src/

SRCDIRS := \
core \
module_interface \
user_interface

SRCDIRS_BSD := \
user_interface/bsd

SRCDIRS_DOS := \
user_interface/dos

SRCDIRS_W32 := \
user_interface/windows \
user_interface/windows/controls \
user_interface/windows/resources \
module_interface/dll

# set the target directory
# check the architecture
ifndef _ARCH
ifdef DOS
_ARCH := dos
endif
ifdef BSD
_ARCH := bsd
else
_ARCH := win32
endif
export _ARCH
endif

# check the release type
ifdef DEBUG
OUT := $(_ARCH)/debug
else
OUT := $(_ARCH)/release
endif

ifdef DOS
SRCDIRS := $(SRCDIRS) $(SRCDIRS_DOS)
endif
ifdef BSD
SRCDIRS := $(SRCDIRS) $(SRCDIRS_BSD)
else
SRCDIRS := $(SRCDIRS) $(SRCDIRS_W32)
endif

VPATH = $(addprefix $(SRCPREFIX), $(SRCDIRS))

test : config.h
@echo VPATH $(VPATH)

endif

--------------------------------------------------------------
Makefile.2

SHELL = /bin/sh

OUTPREFIX = ../build/
SRCPREFIX := ..\..\..\src\

SRCDIRS := \
core \
module_interface \
user_interface

SRCDIRS_BSD := \
user_interface\bsd

SRCDIRS_DOS := \
user_interface\dos

SRCDIRS_W32 := \
user_interface\windows \
user_interface\windows\controls \
user_interface\windows\resources \
module_interface\dll

# set the target directory
# check the architecture
ifndef _ARCH
ifdef DOS
_ARCH := dos
endif
ifdef BSD
_ARCH := bsd
else
_ARCH := win32
endif
export _ARCH
endif

# check the release type
ifdef DEBUG
OUT := $(_ARCH)/debug
else
OUT := $(_ARCH)/release
endif

ifdef DOS
SRCDIRS := $(SRCDIRS) $(SRCDIRS_DOS)
endif
ifdef BSD
SRCDIRS := $(SRCDIRS) $(SRCDIRS_BSD)
else
SRCDIRS := $(SRCDIRS) $(SRCDIRS_W32)
endif

VPATH = $(addprefix $(SRCPREFIX), $(SRCDIRS))

test : config.h
@echo VPATH $(VPATH)

endif

Thanks for any help,

--
Martijn
http://www.sereneconcepts.nl

%% "Martijn" <subscription-NOSPAM-101@hotNOFILTERmail.com> writes:

m> (3.80-3 which is somehow 5 times as big as 3.79.1 - is this bloat normal?)

On Linux, 3.80 is only 3k bigger than 3.89.1 (120k vs 117k). So, I
don't know what's going on with the MINGW port.


I think you're posting to the wrong groups for help with this: there are
likely to be very few Windows-knowledgeable people reading
comp.unix.programmer at least. Your problem is not with the UNIX side
of the equation, but rather with the Windows side.

I suggest you try finding a newsgroup or mailing list related to MINGW
specifically. They will be able to help you find out what's going on.

--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@nortelnetworks.com> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.

Martijn wrote:
[stripped makefiles, see earlier post]

Well, luckily (in an ironic way) the error was in my makefile - but I
find it hard to get the logic behind it. I changed

SRCPREFIX := ../../../src/

to

SRCPREFIX := ../../../src

and

VPATH = $(addprefix $(SRCPREFIX), $(SRCDIRS))

to

VPATH = $(addprefix $(SRCPREFIX)/, $(SRCDIRS))

which got it working. The fact why it worked _better_ (because it turned
out to be broken) with backslashes, because in SRCPREFIX := ..\..\..\src\
the trailing \ was "eaten" by the following newline. Of course this was not
what I wanted (but it created entries such as "..\..\..\src core" in which
the first entry was valid.

As it turns out, after finally getting this all to work, it made my
environment harder to work with, because my editor doesn't like the relative
paths gcc now reports :S.

Thanks to everybody who helped me with this and shame on me ,

--
Martijn
http://www.sereneconcepts.nl