POMAKE fails on relative paths...

[CommonTater]

POMAKE (version 7.00.1) will fail to build this project file...

Code: [Select]


 #
# PROJECT FILE generated by "Pelles C for Windows, version 7.00".
# WARNING! DO NOT EDIT THIS FILE.
#
 
POC_PROJECT_VERSION = 7.00#
POC_PROJECT_TYPE = 3#
POC_PROJECT_OUTPUTDIR = test_out#
POC_PROJECT_RESULTDIR = ..#
POC_PROJECT_ARGUMENTS = #
POC_PROJECT_WORKPATH = .#
POC_PROJECT_EXECUTOR = #
CC = pocc.exe#
AS = poasm.exe#
RC = porc.exe#
LINK = polink.exe#
SIGN = posign.exe#
CCFLAGS = -Tx86-coff -W1 -Zx -Ze -Gd -std:C99#
ASFLAGS = -AIA32 -Gd#
RCFLAGS = -r#
LINKFLAGS = -machine:ix86 -subsystem:console kernel32.lib advapi32.lib delayimp.lib#
SIGNFLAGS = -location:CU -store:MY -timeurl:http://timestamp.verisign.com/scripts/timstamp.dll -errkill#
INCLUDE = $(PellesCDir)\Include\Win;$(PellesCDir)\Include#
LIB = $(PellesCDir)\Lib\Win;$(PellesCDir)\Lib#
 
#
# Build test.exe.
#
..\test.exe: \
 test_out\main.obj
 set LIB=$(LIB)
 $(LINK) $(LINKFLAGS) -out:"$@" $**
 
#
# Build main.obj.
#
test_out\main.obj: \
 main.c
 set INCLUDE=$(INCLUDE)
 $(CC) $(CCFLAGS) "main.c" -Fo"$@"
 
.SILENT:

The ..\test.exe build target is incorrectly interpreted as an intrinsic rule and the linker is never executed.
 
The project builds in POIDE...
 
Also the /R option ignores too much... it should not ignore the MAKEFILE macro giving the path to the makefile (i.e. the working path of POMAKE)
 

[CommonTater]

Bump...

Further testing :  NMake can run .ppj files with relative paths. 

Please fix this...

[AlexN]

Further testing :  NMake can run .ppj files with relative paths. 

Is it possible to put the path to NMake before the path to Pelles C and copy/rename nmake.exe to pomake.exe (and until Pelle fix this)?

[CommonTater]

Further testing :  NMake can run .ppj files with relative paths. 

Is it possible to put the path to NMake before the path to Pelles C and copy/rename nmake.exe to pomake.exe (and until Pelle fix this)?

I suppose it's possible...
 
The IDE builds projects internally and does not exhibit this bug so this only affects command line builds.
 
What I did as a stop gap was to put a copy of NMake in the PellesC\bin folder and use it instead of POMake. I currently have only one job where I use a .BAT file to build several projects, and I just edited it to call NMake instead of POMake.
 
This however doesn't work at the client's office since I can't legally give them a copy of NMake.  They already have Pelles C installed so it would be best if I could get a fixed version of POMake in there...
 

[Vortex]

The Masm forum website provides NMake V1.5 :

http://www.masm32.com/website/microsft.htm

http://www.masm32.com/website/microsoft/nmake15.exe

[CommonTater]

Ummm Vortex, me amigo... you do realize that's 16 it code, don't you?  Won't run in x64 at all.

However, I'm guessing this means I can probably give my client a newer version without fear of the big boot stomping down on me... That will solve my immediate problem, at least until POMake is fixed.

[TimoVJL]

Open that package with 7-Zip or UniExtract.

[CommonTater]

Open that package with 7-Zip or UniExtract.

No worries Timo... I have it working with a copy from the SDK.

Next week's project is to get the build converted over to .bat files with Build Check.... then we should all be happy.

[Vortex]

Hi CommonTater,

The executable pointed by

http://www.masm32.com/website/microsoft/nmake15.exe

is a SFX archive. After running it, you get NMAKE.EXE 32-bit.