I originally posted this to fpc-pascal but didn't get much of a response. The problem where having spaces in the environmental variable will error out the Make process has been described.

Here is a work around I came up with:

It seems to work on my system. Could someone check this out and add to code base if okay?

Open Lazarus\Designer\Makefile
Find this text:

override PATH:=$(subst \,/,$(PATH))
ifeq ($(findstring ;,$(PATH)),)
inUnix=1
SEARCHPATH:=$(filter-out .,$(subst :, ,$(PATH)))
else
SEARCHPATH:=$(subst ;, ,$(PATH))
endif
PWD:=$(strip $(wildcard $(addsuffix /pwd.exe,$(SEARCHPATH)))) ifeq ($(PWD),)
PWD:=$(strip $(wildcard $(addsuffix /pwd,$(SEARCHPATH)))) ifeq ($(PWD),)
$(error You need the GNU utils package to use this Makefile)

Replace with:

override PATH:=$(subst \,/,$(PATH))
# Empty variable
E :=
# Variable containing one space (space char between two empty vars) S := $E $E
# TEMPPATH is a variable contained the PATH environmental var with spaces replaced with "*"
TEMPPATH:=$(subst $S,*,$(PATH))
# now, delimeters for directory names (:,;) are replaced with spaces ifeq ($(findstring ;,$(TEMPPATH)),)
inUnix=1
SEARCHPATH:=$(filter-out .,$(subst :, ,$(TEMPPATH))) else
SEARCHPATH:=$(subst ;, ,$(TEMPPATH))
endif
# now, add the suffix "/pwd.exe" to the end of each space-delimted word in the path
TEMPPWD:=$(addsuffix /pwd.exe, $(SEARCHPATH))
# change *'s back to spaces before continuing
TEMPPWD:=$(subst *, ,$(TEMPPWD))
PWD:=$(firstword $(wildcard $(TEMPPWD)))
ifeq ($(PWD),)
TEMPPWD:=$(addsuffix /pwd, $(SEARCHPATH)))
TEMPPWD:=$(subst *, ,$(TEMPPWD))
PWD:=$(firstword $(wildcard $(TEMPPWD)))
ifeq ($(PWD),)
$(error You need the GNU utils package to use this Makefile)

It looks like a hack. Maybe it can fix this issue for pwd.exe, but it occurres more often in Makefiles. Those other parts will then still fail.

It looks like a hack. Maybe it can fix this issue for pwd.exe, but it occurres more often in Makefiles. Those other parts will then still fail.

Peter,

I agree with you. However, Make is unwilling to fix the problem. They feel that having spaces in the path or in filenames is bad programming and won't support the function.

We checked the workaround and it allowed us to compile Lazarus. Before we couldn't.

Any other ideas what we could do to address the problem?

Best wishes,
Bob

Write a make replacement that supports Makefile.fpc/Lazarus package descriptions.

Hello all,
Today I built last compiler (1.9.5) from sources. Then I tried to compile a small test win32 dll with -CX -XX and got a binary without export functions entries. That is interesting that using -a option (using external assembler) solves this problem.

Hello all,
10 years ago I programmed a little on ThinkPascal therefore could point to some inconveniences that seem to be reproduced in FPC.

As is known, common file names are not enough in MacOS to comfortable file access via shell, they need also two hiden extensions, type and creator. Think pascal didn't allow (at least, I got the flavour working without manuals) set these extensions by using standard file types, reset/rewrite etc and gave e.g. 'TEXT' or 'DATA' for ftype automatically. I see, in current MacOS RTL. But I think, no reason is here to use only direct API calls. If two writeable typized constants, Creator:OSType=$522A6368;fileType:= $54455854, will be added into INTERFACE section, the programmer will be easy change them later.

E.g., as in this sample:

var
 f:file;
 TC:packed record
  case byte of
   0:(x:OSType);
   1:(s:array[0..3]of char)
 end;
begin
 TC.s:='MyDt';
 fileType:=TC.x;
 TC.s:='CoOL';
 creator:=TC.x;
 assign(f,'My File');
 reset(f,1);
....

I think, this way is not very beautiful but it is not worse than e.g. using filemode variable to change file access rights.

Also some notes about some ThinkPascal features.

1) Think Pascal doesn't support assign/assignfile procedures. Instead, it allows to use a file name as a additional parameter for rewrite, reset or open procedures. I think, a additional unit could be written that could mimic this behavior.
2) Think Pascal supports get and put procedures and access to file buffer via ^ operator.

These are all know issues. 1.9.5 is unstable and not recommended.

04-06-29 09.38, skrev Pavel V. Ozerski följande:

If it is possible, I will try to add this.

I will probably add this also, as overloaded procedures, to a comming macpas unit which would be included automatically if mode macpas is used.

2) Think Pascal supports get and put procedures and access to file buffer via ^ operator.

Is this really used by many programmers ?

Is this standard Pascal ?

Thank you for your opinons/ Olle

Olle Raab said:

If you decide to do it, let's try to find some solution that could be compatible to other platforms as well (and possibly just ignored on others where it doesn't make any sense). This kind of information can be provided for OS/2 as well (although not strictly necessary), but the values are just text, not hardcoded numbers. Do you have any idea how to create something which could be supported under both (and possibly other) targets at the same time, without a need for using different values for different systems? Is there any way to convert the above listed hexadecimal numbers to their text descriptions (and back) on MacOS?

In addition, there should be probably a procedure created for changing the values instead of giving direct access to those variables (the current values should be internally stored in threadvars probably).

Tomas

04-06-29 09.38, skrev Pavel V. Ozerski följande:

Now this 2 proc are added to rtl/macos/system.pp:

procedure SetDefaultMacOSFiletype(ftype: ShortString);
procedure SetDefaultMacOSCreator(creator: ShortString);

Olle