Everytime I update, lately I run into issues....

problem is th "/" which is not regognized by windows. ./fpmake.exe

windows believes "." is the command.

make.exe -C fcl-web smart
make.exe[3]: Entering directory `C:/FPC/SVN/trunc/packages/fcl-web' C:/FPC/SVN/trunc/compiler/ppc386.exe fpmake.pp
-FuC:/FPC/SVN/trunc/rtl/units/i386-win32
-FuC:/FPC/SVN/trunc/packages/hash/units/i386-win32 -FuC:/FPC/SVN/trunc/packages/paszlib/units/i386-win32 -FuC:/FPC/SVN/trunc/packages/fcl-process/units/i386-win32 -FuC:/FPC/SVN/trunc/packages
/fpmkunit/units/i386-win32
./fpmake.exe build --localunitdir=../.. --globalunitdir=.. --os=win32 --cpu=i386 -o -XX -o -CX -o -Ur -o -Xs -o -O2 -o -n -o -O2 -o -FuC:/FP C/SVN/trunc/rtl/units/i386-win32 -o
-FuC:/FPC/SVN/trunc/packages/hash/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/paszlib/units/i386-wi n32 -o -FuC:/FPC/SVN/trunc/packages/fcl-process/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/fpmkunit/units/i386-win32 -o -FE. -o -FUuni ts/i386-win32 -o -gl -o -O3 -o -Or -o -CpPENTIUMM -o -OpPENTIUMM -o -di386 -o -dRELEASE --compiler=C:/FPC/SVN/trunc/compiler/ppc386.exe -o " -XX -CX"
'.' is not recognized as an internal or external command, operable program or batch file.
make.exe[3]: *** [smart] Error 1
make.exe[3]: Leaving directory `C:/FPC/SVN/trunc/packages/fcl-web' make.exe[2]: *** [fcl-web_smart] Error 2
make.exe[2]: Leaving directory `C:/FPC/SVN/trunc/packages' make.exe[1]: *** [packages_smart] Error 2
make.exe[1]: Leaving directory `C:/FPC/SVN/trunc'
make.exe: *** [build-stamp.i386-win32] Error 2

That's kind of strange, because from

LOCALFPMAKE=.$(PATHSEP)fpmake$(SRCEXEEXT)

I would guess that the correct pathsep is used (namely \ under windows)

LOCALFPMAKE is the command used to compile the lot.

Michael.

Well what can I do do provide more info?

btw: sorry for the upper-case subject, just a lot of other things, and then this on top...

From makefile.fpc

# clean by replacing the command with 'echo'
FPMAKE_BIN_CLEAN=$(wildcard ./fpmake$(SRCEXEEXT))

Not sure if related, it happened in make, not clean....

Ok, so I started changing the makefile, to see why patsep goes wrong

Right on top of the makefile:

ifeq ($(findstring ;,$(PATH)),)
inUnix=1
SEARCHPATH:=$(filter-out .,$(subst :, ,$(PATH)))

if I change it to
inUnixXX=1
then it works

so it seems that this test, reports my windows system as unix?

$(PATH) => is that the environment?

here is my PATH

PATH=C:\FPC\SVN\trunk_build

I removed all the other stuff from it, trunk_build has all that is needed. So there is no inteference from any other installed product...

Removing all stuff from it is what is causing the problem. The OS detection is based on checking whether or not the PATH contains a semicolon. If it doesn't, we assume it's Unix (it has always worked like that).

Jonas

Ok, it was an easy fix. I added a trailing ";"

However, the makefiles for building the compiler, (and probably rtl) did not have a happened during a full make (after a full "make clean") So both compiler and rtl should have been build, before packages? fcl-web is then probably just the first package....

btw: isn't ";" a valid char in a unix pathname?

fcl-web is the only package that currently uses fpmake for building.

btw: isn't ";" a valid char in a unix pathname?

Yes, but it's quite rare. It's simply the best way we have found to detect Unix environments via the Makefile. A better way is always welcome.

Jonas

I am no expert at this, but for example a "/" is not allowed in windows filenames (so it should not be in windows course a user can still put it in there...)
On unix, it is likely to be there => unless the path is almost empty

Can the makefile check the existence of a directory? (and would this check obey the \/ difference?)
If so (the root directory) / should always exist on unix. But on windows "/" is not allowed in filenames, and can not exist.

Only I do not know, what happens with mounted filesystems....

or test if ./known.file exists...

Afaik this doesn't hold anymore if you run make inside a cygwin shell.

Jonas

Right but iirc cygwin was detected on it's own, and PATHSEP for cygwin was / anyway

Anyway, if cygwin allows / then it wouldn't matter if / was used? Of course other settings may be affected...

As I said, makefiles are not exactly my strong side...

Indeed. Then it must have been something else.

Anyway, if cygwin allows / then it wouldn't matter if / was used? Of course other settings may be affected...

Many other settings are affected (default search location for the "fpc" binary, extension of executables and script files, calling the zipper, installing files, ...).

Jonas

happily accepts a forward slash in a path:

Just did the above in a DOS shell on Windows XPSP3. And I just tested this on Windows 7 Pro as well, with the same basic result. Internally, all path related functions of Windows allow AFAIK both forward and backwards slashes, it's just the GUI that doesn't allow you to enter the forward slash...

Ralf

11.06.2011 2:26, Ralf A. Quint пишет:

My mileage varies (Windows XP SP3 Russian):

C:\Documents and Settings>cd /winnt
Системе не удается найти указанный путь.

C:\Documents and Settings>cd \winnt

C:\WINNT>./notepad.exe
"." не является внутренней или внешней командой, исполняемой программой или пакетным файлом.

C:\WINNT>

Perhaps it depends on localization or some other factors.

Sergei

In our previous episode, Martin said:

The windows shell also accepts / as pathseparator.

Not here it doesn't. Just tested:

C:\Documents and Settings\Administrator>cd c:/programs C:\Documents and Settings\Administrator

C:\Documents and Settings\Administrator>cd c:\programs

C:\Programs>

Michael.

In our previous episode, Michael Van Canneyt said:

After retest it seems only to ignore it indeed. Try going to the root and then do

cd c:/programs

Hello FPC,

Saturday, June 11, 2011, 10:48:31 AM, you wrote:

MvdV> In our previous episode, Michael Van Canneyt said:

MvdV> After retest it seems only to ignore it indeed. Try going to the root and MvdV> then do

'/' is used as path separator, but not as path root indicator, so '/' can only be used with relative paths:

cd \/Programs (go to root, then programs)
cd /p1/p2/p3 (enter in p1, then p2, then p3)
cd /../../.. (up 3 directories)

Jonas Maebe wrote

> btw: isn't ";" a valid char in a unix pathname? Yes, but it's quite rare. It's simply the best way we have found to detect Unix environments via the Makefile. A better way is always welcome.

Today all windowes should have set the environment variable WINDIR.

The current test isn't about Windows but DOS-like versus Unix-like. My OS/2 surely doesn't use windir. ;-)

Tomas

But is the inUnix define only used by the Makefile that runs fpmake? I can hardly believe that.

Joost.

Joost van der Sluis wrote

But is the inUnix define only used by the Makefile that runs fpmake? I can hardly believe that.

It's mostly used by "make install" functionality.

Jonas