Pelles C forum
Pelles C => Bug reports => Topic started by: CommonTater on August 30, 2012, 07:39:03 AM
-
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...
-
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)?
-
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.
-
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.