Thanks for spotting the two Main() functions. I missed that because I was ignoring it in my main app. There a PRG was getting compiled into the app that wasn't supposed to be and the app was running fine, so I ignored it. It the test case it was significant.
The only change you made to the make file I note is that you changed the path for the C files from .\obj to .\ . However, I have my C files in .\obj so I get this error when the path is changed:
Fatal: '.\alert.c' does not exist - don't know how to make it
Of course this is expected.
So I changed it back and it compiles fine. However, there is still a problem and perhaps the location of the C files is related. I still do not get a recompile when any PRG is changed. I am guessing that this is the line that looks for changes:
Alert.exe : $(PRG:.PRG=.OBJ) $(C:.C=.OBJ)
Perhaps this is a path issue? Do the paths need to be added to the above, or is the make file supposed to already know where the OBJs and C files are? It seems to know elsewhere in the make file.
Where are the C files normally stored, with the PRGs or with the OBJs. Or someplace else?
The old Clipper RMake.exe was so easy compared to Borland's Make. Sigh.
Yes, I know that. But the make file is not checking the dates and times of the OBJs and the Cs against the PRGs when a PRG is changed. So either it is trying and it can't find the files, or it is not checking at all. I am trying to figure out which and how to fix it.
Try editing the One.prg file (just change the message displayed) and then try running the make file again. The old message will still be displayed and if you look at the date and time of the Alert.exe it will not have changed even though the One.prg was changed.
I am beginning to think it would be easier to write my own make file utility rather than trying to figure out Borland's make.exe works.
Try editing the One.prg file (just change the message displayed) and then try running the make file again. The old message will still be displayed and if you look at the date and time of the Alert.exe it will not have changed even though the One.prg was changed.
Actually, I said this wrong.
The Alert.exe will be updated (it is recompiled) but the one.c and one.obj files are not updated. So the new Alert.exe is the same as the last one even though it was recompiled. I just did this again and here are my file dates and times:
This is probably the same one I sent you in a zip file a couple of days ago. I don't think I have made any changes since then. Well, I may have made some changes then changed them back. Anyway this is the most current one.
.path.OBJ = .\obj
.path.PRG = .\
.path.CH = $(FWDIR)\include;$(HBDIR)\include
#.path.C = .\obj thats is wrong, see next line
.path.C = .\
.path.rc = .\
#important: Use Uppercase for filenames extensions, in the next two rules!
PRG = \
alert.PRG \
one.PRG
C = \
#there you have note only files which source is in C-Code delete your lines alert.c and one.c
#two.C
PROJECT : Alert.exe
# and rest of your mak-file
Putting the C files in or not makes no difference. If a PRG is edited and saved, the C and OBJs are not regenerated. It just relinks the EXE without the changes using the old OBJs.
I can't figure out how to force the make file to check the date-time stamps and then recompile if needed.
I had all kinds of trouble after copying all your files from your previous message. Mostly they were due to the fact that the forum replaces tabs with spaces. Now I am still getting this error:
C:\Users\James\Documents\Projects\Make\Antonio>c:\bcc7\bin\make -f test.mak
MAKE Version 5.41 Copyright (c) 1987, 2014 Embarcadero Technologies, Inc.
Fatal: ' ' does not exist - don't know how to make it
Process completed, Exit Code 1.
Execution time: 00:00.217
Which, of course, is not helpful at all. I do note that only the alert.obj and alert.c files were generated, not the files for One.prg.
Will you please send me all the files in a zip (no need to rename "zip").
Fatal: Too many DEF file names: c:\bcc7\lib\psdk\rasapi32.lib
I have never seen that before, and I don't know what it means.
If I leave that LIB out, then I get the same error at the next LIB in the list. I can't imagine that six lines of code would cause this, so the problem seems like it is not in the code.
I found an explanation on the Embarcadero site, but it doesn't help much:
