POMAKE (version 7.00.1) will fail to build this project file...
#
# 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)
Bump...
Further testing : NMake can run .ppj files with relative paths.
Please fix this...
Quote from: CommonTater on September 22, 2012, 05:29:45 PM
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)?
Quote from: AlexN on September 26, 2012, 01:00:44 PM
Quote from: CommonTater on September 22, 2012, 05:29:45 PM
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...
The Masm forum website provides NMake V1.5 :
http://www.masm32.com/website/microsft.htm
http://www.masm32.com/website/microsoft/nmake15.exe
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.
Open that package with 7-Zip or UniExtract.
Quote from: timovjl on September 28, 2012, 07:17:42 AM
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.
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.