Maurice Lombardi wrote:
I succeeded in this native building with only one change to gpc sources due to a DOS peculiarity. The problem comes from the following lines contained (at two different locations) in p/Make-lang-2.95.in
CC="`echo $(GCC_FOR_TARGET) | sed -e 's,-B\([^/]\),-B../../\1,g' -e's,^([^/][^ ]*),../../\1,'`" \ PC="`echo $(GPC_FOR_TARGET) | sed -e 's,-B([^/]),-B../../\1,g' -e 's,^([^/][^ ]*),../../\1,'`" \
It means that to go the to rts subdirectory it prepends ../.. to G?C_FOR_TARGET if this is a relative, not an absolute directory name. Absolute is recognized by the first character being a slash. However in DOS an absolute pathname starts with a drive letter c:/ In particular GCC_FOR_TARGET is in my case an absolute pathname built through `pwd` in the top makefile, which gives the drive letter. Solutions could be
- saying that an absolute pathname has either / as first character or : as
second. Can be garbled by a unix relative path starting with d: is this possible in this context? This gives the attached notroot.dif
- saying that a relative pathname starts by ./ or ../ This is what occurs for
GPC_FOR_TARGET. Can be garbled if the relative path starts with an ordinary character, is this possible in this context? This gives the attached relative.dif. You can incorporate one of these solutions (or a better you may imagine) into the gpc sources, or let the djgpp maintainers to make the patch only for djgpp (and probably other DOS systems). The last solution would mean however the need to modify the patch for each new gpc alpha or beta distribution, so that the first is highly preferred.
As you say, it can garble unix paths starting with `d:', and also (Unix and Dos) paths consisting of only 1 letter, in particular `.'. I don't know the build process of gcc-2.95 well, so I don't know if these are possible in this context, but it's possible to modify the substitution so as to recognize 1-letter paths. The following should do the trick, but is *untested*:
's,-B([^/]([^:].*)?)$$,-B../../\1,g'
(The double `$' is necessary when using it in a Makefile.)
Furthermore, in order to restrict the change only to Dos systems, I suggest the following:
- Make the substitution (the string above) a make variable.
- Set it to the Unix substitution by using an assignment in the Makefile.
- Make sure the variable is transported to sub-makes (see GPC_FLAGS_TO_PASS, GPC_INSTALL_FLAGS_TO_PASS).
- When building under Dos, you can override the value on the command line (takes precedence over assignments in the Makefile). You can put this in a batch file or whatever you use to invoke make.
- Alternatively, you can hack config-lang.in to add this value automatically on Dos systems, but I can't give you any advice about this, since I don't know this stuff well.
For those interested to internals of djgpp. The beta bash version enables (when setting PATH_EXPAND=N) pwd to output /dev/c/ instead of c: to have a more unix-like behavior, which seems to solve the above problem. Bash understands command lines starting with /dev/c/bin/something.exe but DOS (command.com) does not understand ! Now, as explained to me by Eli Zaretskii to solve an other hairy problem, the djgpp port of Make sends command lines to bash only if he thinks that the shell is involved, and to COMMAND.COM otherwise (to save overhead). He recognizes that the shell is needed if the make line includes something which belongs to the shell, which could be a simple ; at the end of the makefile line. I have tried to build with PATH_EXPAND=N, it stops building the rts at the first command line $(GCC_FOR_TARGET) so so When adding a ; at the end of that makefile line, make goes somewhat further, but stops at the next occurrence, which shows that this is indeed the problem. Now is the overhead in make large enough to warrant all these inconveniences?
I'm not sure, though I would guess not, as far as GPC's build process is concerned. But if I understood you right, there's nothing we can do about it anyway, because that happens to be make's behaviour under DJGPP, doesn't it?
Frank