Re: [fpc-devel] compiler bug?

2005-01-02 Thread Nico Aragón
El Jueves, 30 de Diciembre de 2004 22:01, peter green escribiste:
 you are forciblly putting an out of range value in a variable what do you
 expect to happen?

I think it's slightly subtler. I guess that this code:

  if not b then
 WriteLn('False')
  else if b then
 WriteLn('True')
  else
 WriteLn('Other');

...could throw a different result.

IIRC, any non-zero value is evaluated as True for a Boolean variable. The 
problem with the case statement is that Jesús is asking the compiler which 
specific value it chooses for assignements... and getting surprised because 
it's not what he expected. I guess the compiler uses 1 instead of 255. But 
it's surely documented anyway.

-- 
saludos,

Nico Aragón
[EMAIL PROTECTED]
http://espira.net/nico/


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Portability Standards

2005-01-02 Thread Michael Van Canneyt


On Sat, 1 Jan 2005, DrDiettrich wrote:

 In the meantime I downloaded the Abbrevia package from SourceForge, and
 came across several unpleasent constructs. Please let me introduce my
 preferred programming model for portable code.

 1) Target Dependencies
 I don't accept any OS or machine specific conditional compilation in
 code, except in dedicated units. In Abbrevia the same fixes occur in
 various places in the code, instead of in a dedicated OS specific
 procedure. Such a procedure exists, but unfortunately only in the
 unpatched form :-(
 Also compiler specific conditionals should be used only where absolutely
 necessary (local options, syntax differences...).

Agreed 100%.
In general, a component suite should have all os-dependent code in a single
unit, presenting the rest of the suite with a uniform API.


 2) Code Checks
 It should be possible to check code for compilation on other platforms.
 This requires that target specific code can be compiled on any host,
 somehow. Consequently it must be possible to override the compiler
 generated symbols that describe the environment.

Why, you can simply cross-compile ?


 3) Standard Units
 Portable code shall use standard procedures and units for target
 specific actions. This requires the definition, implementation, and
 consequential use of one or more standard units for:
 - Machine specific data types and procedures (endianness...)

Compiler defines the endianness.
System unit has 'guaranteed' types.

 - OS specific data types and procedures

? This is not portable.

 - C and POSIX specific data types (for code ported from GNU/C)
 Then it should be clear which portable data types and procedures should
 be taken from which unit. It also should be easier to determine which
 procedures need special considerations in portable code, from the
 defined data types and procedures in these units.

 It's not necessary that everybody follows these principles, but I will
 do so in my own published portable code. Otherwise I can continue to
 write my code for Delphi, and let it to somebody else to port that code
 to e.g. FPC.

 In the simplest case these units will have an unconditional interface
 part, the target specific data type declarations and the implementation
 part can be included conditionally from the appropriate locations. For
 testing purposes fake units or code sections can contain the OS specific
 procedure declarations, with empty bodies. This way I could verify that
 my changes to the main stream code would not break the code for other
 environments, due to the use of not yet ported constants or data types
 etc.

 This model has one disadvantage, in so far as complex procedures with
 small embedded platform specific code could no more be checked, because
 it often was impossible to determine the impact of changes to local
 variables etc. in the conditionally excluded code. It also was and is
 impossible to automatically verify that the conditional sections really
 are implemented for every target!

 In another implementation of a target independent library I defined
 portable classes with standardized methods. These virtual methods were
 almost abstract in the base class, so that they had to be overridden in
 every derived class. In the initialization section of the unit the
 appropriate class was created and assigned to the according variable,
 based on the actual or desired target environment. Of course this
 approach has the disadvantage of increasing runtime (how much?), due to
 the virtual method calls. Nonetheless I think that in many cases the
 difference from the traditional method will not be noticeable, due to
 the (unknown, long?) runtime spent in the embedded OS calls.

 The best compromise might be a mix of both methods. The interface can be
 fully procedural, and objects with virtual methods are used only in the
 implementation part, and only when this approach makes sense. Perhaps
 somebody finds another way to achieve the same goal, with less
 disadvantages?


I don't think you should worry about virtuals. For archiving purposes,
it's the compression/decompression algorithms that will take most time,
and tha actual reading/writing from stream.


 I'm willing to demonstrate my ideas in a redesign and extension of
 Abbrevia, so that we have a concreter base for further discussions. But
 before starting with that work I would like to hear some encouraging g
 opinions or suggestions.

I think you can do this. I will be pleased to help where I can.
But send a proposal before you start, I wouldn't want to you
end up rewriting half your code after a discussion. ;-)

Michael.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel] Demo prog problem

2005-01-02 Thread John Taylor
Hi,

As someone new to Pascal and to FreePascal, I've tried to compile and run
the supplied demo pascal programs. However, I'm having trouble compiling
dlltest.pp. I get a compile error dlltest.pp(15,24) Fatal:syntax error. :
expected but const string found. testdll.pp compiled OK and created a .dll.
Also winhello.pp compiled and run OK.

Can someone let me know what is the problem compiling dlltest.pp please?
Note that I'm not yet subscribed to the list so can you copy email reply to
me please.

Thanks in advance for any help.

John.



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out

2005-01-02 Thread Michael . VanCanneyt

Hello,

The Free Pascal Team is pleased to announce that FPC version 1.9.6
(or 2.0.0-RC1) is available and ready for download.

This is a pre-release of version 2.0. As such, it is considered a beta of
the upcoming 2.0 release, which is expected to be released in one or two
months from here.

While this is officially a beta, we believe that this version is release
quality. We would very much like you download and install this version, and
give any feedback regarding bugs and other issues.

If no major bugs are found, version 2.0 will be released in a short
timeframe.

Highlights in this version:

Compiler:
  + New platforms: 
- Linux: x86_64, amd64, sparc, PowerPC architectures.
- Mac OS and Mac OS X (Darwin).
- Netware Libc.
- MorphOS.
  + Code generation improvements: 
 Register variable support (-Or) for all targets, better inlining support.
  + MacPas compiler mode (-Mmacpas).
  
RTL/FCL/FV:
  + New heap manager that releases memory back to the OS.
  + TThread.Synchronize support.
  + Further additions for improved Delphi compatibility.
  + Many other additions (RTTIUtils, new Datasets, FPCUnit test framework).
  * Free Vision Updated to fvision implementation, first official release.

IDE:
  * Lots of improvements and stability fixes.
  * Support latest gdb 6.2.x and 6.3.x releases.

Docs:
  + Lots of updates.
  + Easier to navigate html documentation.
  * fpDoc is used to generate all unit documentation.

And of course many many bugfixes.

A complete list of changes can be found in the whatsnew.txt file in the
distribution.

Downloads are available from the website for the following platforms:
- Darwin (Mac OS X)
- Dos (Go32V2)
- FreeBSD
- Linux (I386/Sparc/PPC/x86_64 (amd64))
- Mac OS
- Netware (clib and libc)
- OS/2 (native)
- Win32

To download, go to 
  http://www.freepascal.org/sdown.html
and select a mirror near you. Look in the section 'official beta releases' 
and select the platform of your choice; then follow the download
instructions. 

If you choose the SourceForge mirror, the download instructions are
different. Also note that sourceforge mirrors are not immediatly up-to-date.

Enjoy it, and a Happy New Year from

  The Free Pascal team.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] compiler bug?

2005-01-02 Thread Jose Manuel

 I think it's slightly subtler. I guess that this code:

   if not b then
  WriteLn('False')
   else if b then
  WriteLn('True')
   else
  WriteLn('Other');

 ...could throw a different result.

 IIRC, any non-zero value is evaluated as True for a Boolean
 variable. The

No, and no. There your assuming some implementation of the type Boolean.
I Peter stated, bitwise logic and Boolean logic are neatly separated in
Pacal. You say you're not counting on how it's implemented and still insists
in expressions as True  0. No way.

 problem with the case statement is that Jesús is asking the
 compiler which
 specific value it chooses for assignements... and getting
 surprised because
 it's not what he expected. I guess the compiler uses 1 instead of
 ¨¨¨
 255. But

Dodi told you, Peter told you and I tell you now. Don't guess anything about
how a compiler internally implementens a type. Peter could have said so
louder but not clearer: if you cast a type into another type that can result
in an overflow, it's programmer's fault, 'cause at least in Pascal
(exceptions apart) those cast have to be done explicitly. And you can't
trust wheter True is 255, 1, -1 or use simply another bit pattern or
whathever, which is perfectly legal, Don't ya say you agree with everyone
when you are clearly on the contrary.


I think this is goin' far behind this list is intended to. All I can say is
that there should be some kind of compatibility for those who, as me (:-(
guilty), sometimes recurre to Fix'n Dirty, I mean: FPC (at least in FPCOBJ
or DELPHI compatibilty mode), Kilyx and Delphy should behave the same, but
as long as Kylix and Delphi don't keep the same (sane?) behaviour, it's up
to you, FPC developers to choose what you find more (efficient?, accurate to
reality, compatible? I dunno, but surely you do)
Anyway, I think it's pointless to go on with this

 it's surely documented anyway.

The internal implementation of a Boolean type, I guess it ain't? Surely for
every compiler it is, but there's no standard way and I'm quite sure there's
no standard how it should behave when typecasting.

 --
 saludos,

 Nico Aragón

Bye, Nico and everyone.

--
  JMR

BTW: I don't wish everyone Happy Christmas 'cause there are a lot of
religions, and to too many of them, Christmas has no sense. Anyhow my best
wishes to everyone

For Dodi's Sake (What he asked Nico about his 'rudimentary spanish'), and to
anyone who might be interested:

a) ¡Hola, Torpedo!
That's slang. You could translate it into 'Hi, Dork!'

b) Feliz Año:
In effect, it's the same as in English: It means merely: 'Happy new year!'






___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] fpUmask in Darwin

2005-01-02 Thread Jonas Maebe
On 31 dec 2004, at 02:00, Gary Handelman wrote:
Does anyone know what happened to the fpUmask function under fpc
Darwin 1.9.5 [2004/08/08] for powerpc?  I'm guessing that It's
supposed to be in the baseunix unit, and I have verified this under
fpc Linux 1.9.4 [2004/05/30] for i386.
Using the Darwin compiler gives me: Identifier not found fpUmask.
This has been added in 1.9.7, the fix didn't make it in time for 1.9.6
Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Optimization error causes pyacc and plex to fail

2005-01-02 Thread Jonas Maebe
On 1 jan 2005, at 19:49, [EMAIL PROTECTED] wrote:
Can't seem to get bug submission to work so I'm sending this here.
The 1.9.x distributed binaries of plex and pyacc both fail, as well as 
any created from a 1.9.5 source snapshot. plex ends normally but only 
creates 2 states. pyacc fails with a RTE 216 on a move in procedure 
setunion of yaccbase. The makefile compiles these programs with the 
-OG2p3 option. Changing this to either -Og2p3 or -OG1p3 and they both 
work correctly. I am using unmodified versions of both programs so am 
only attaching the output of each scenario. Feel free to contact me if 
you need anything else.
Could you try again with the 1.9.6 release? Several optimizer bugs have 
been fixed this week. I can't test since I don't have any yacc/lex 
grammar available.

Thanks,
Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Portability Standards

2005-01-02 Thread DrDiettrich
Michael Van Canneyt wrote:

  1) Target Dependencies

 Agreed 100%.
 In general, a component suite should have all os-dependent code in a single
 unit, presenting the rest of the suite with a uniform API.

Fine :-)
But how should that code be implemented? For various target platforms?


  2) Code Checks

 Why, you can simply cross-compile ?

No, I can't, neither in Delphi nor (AFAIK) in the Windows version of
fpc.


  3) Standard Units

 Compiler defines the endianness.

Correct, but this definition must be evaluated to produce the
appropriate code. E.g. RPM defines a function htonl, read:
HostToNetworkLong, that then is used to convert Long values in Network
byte order (big endian?) into the Host byte order. Such a function
should reside in a common unit, where the according implementation
depends on the endianness of the host machine. It also should have an
handy name, so that it's almost obvious how to replace htonl in the
ported code.

 System unit has 'guaranteed' types.

Fine, but these names often are not very descriptive, like ShortInt and
SmallInt. Names like cUInt16 make it more obvious that this type has a
fixed size and is unsigned.  More standard C names have to be mapped to
the predefined types. E.g. in Abbrevia the file size type (IMO)
initially has been Integer, later was conditionally extended to LongInt
and then to Int64, depending on the capabilities of the compiler and
platform. Here it can be seen that a replacement of some type by the
currently appropriate System standard name is not a good idea. A
distinct data type like off_t (standard C) would make all related
adaptations much simpler, with exactly one definition of that data type.

  - OS specific data types and procedures
 
 ? This is not portable.

When porting code, that was written for a specific platform, the names
of the procedures and related data types should not be changed. Instead
these procedures should be declared in a general unit, together with the
according implementations for other platforms. Please note the different
handling of OS functions and types, where the names should not be
changed, in contrast to the htonl function mentioned above, that should
be renamed to the according (to be defined) common procedure name.

  The best compromise might be a mix of both methods. The interface can be
  fully procedural, and objects with virtual methods are used only in the
  implementation part, and only when this approach makes sense. Perhaps
  somebody finds another way to achieve the same goal, with less
  disadvantages?
 
 
 I don't think you should worry about virtuals.

I don't worry at all, but many people (assembler freaks...) will. That's
why I want to collect opinions before proceeding.

 For archiving purposes,
 it's the compression/decompression algorithms that will take most time,
 and tha actual reading/writing from stream.

This is an rather obvious case, but there exist other cases...


  I'm willing to demonstrate my ideas in a redesign and extension of
  Abbrevia, so that we have a concreter base for further discussions. But
  before starting with that work I would like to hear some encouraging g
  opinions or suggestions.
 
 I think you can do this. I will be pleased to help where I can.
 But send a proposal before you start, I wouldn't want to you
 end up rewriting half your code after a discussion. ;-)

After a closer look at Abbrevia I'm not sure whether it's a good example
for porting code. The recent Kylix extension is crap, and also the
preceding conversions into Windows specific procedures and Pascal
standard types must be reverted to the original definitions. That's why
I'd prefer to use the better ported and portable code from e.g. zlib and
bzip2, instead of again porting the according miserable code from
Abbrevia. More to follow...

DoDi



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Portability Standards

2005-01-02 Thread DrDiettrich
Michael Van Canneyt wrote:

  I'm willing to demonstrate my ideas in a redesign and extension of
  Abbrevia, so that we have a concreter base for further discussions. But
  before starting with that work I would like to hear some encouraging g
  opinions or suggestions.
 
 I think you can do this. I will be pleased to help where I can.
 But send a proposal before you start, I wouldn't want to you
 end up rewriting half your code after a discussion. ;-)

Here some comments and questions about the Abbrevia port.

1) Conditionals
I've redesigned the AbDefine.inc file, with two important changes:

In the first place a DEBUG symbol allows to replace everything else by
another AbDebug.inc file. This switch will allow (me) to define the OS
etc. at will, for debugging purposes. Defining this symbol and the file
contents is entirely up to the user, the file will not occur in CVS or
any distribution.

In the next place the FPC symbol is used to replace the Borland specific
part by an AbFpc.inc file. This file, with an appropriate name, can be
contributed by some FPC user, I don't care for this conditional branch
for now.

Question: Rename all files? All lowercase...?

The LINUX symbol can clash with the according FPC symbol. It should be
renamed e.g. into KYLIX - does somebody know what Kylix defines for
itself?

Question: How to use the FPC provided target symbols?
I'm not happy with the UNIX keyword, I'd used POSIX instead. But that's
only my opinion, I don't want to introduce another symbol.
I'm also not familiar with the differences between the Unix/POSIX
systems. Currently I make no according differences myself, I only
separate the existing code into conditional MSWINDOWS and UNIX parts.


2) File Restructuring
I've separated the spaghetti code in AbUtils.pas into distinct MSWINDOWS
and UNIX sections, each containing complete procedures. These sections
could be moved into dedicated OS specific include files - what's the
preferred way?

It may be desireable to use another dedicated unit for strictly platform
dependent procedures, apart from AbUtils?

According to my first impression of the Abbrevia coding conventions I'd
prefer to use the existing and better ported and portable code in the
already existing paszlib and bzip2 libraries, instead of porting the
according Abbrevia implementations. Perhaps the whole de/compressor part
of Abbrevia could be reduced to the base classes, from which inherit the
new wrappers for the FPC ports.

Question: What's preferrable, a direct port of the Abbrevia library, or
a new and better portable design instead, that interfaces with the not
otherwise available worker classes as implemented in Abbrevia?

A direct port IMO requires more work than a redesign.
In a redesign also much Windows/Delphi/Kylix specific stuff could be
removed or replaced by more portable procedures. The entire file
handling stuff in Abbrevia IMO is too Windows-centric, the Linux/Kylix
extensions only are patchwork that tries to map the Windows file
handling to the very different POSIX file handling, what can result in
loss of file attributes on POSIX platforms.


3) Data Types
off_t now replaces the Integer/LongInt/Int64 mess, for all file size
related values. I took this name from the C standard, but perhaps it
should be replaced by some Pascal name?
IMO this type also should be used in the TStream classes, replacing the
current conditional distinction (seek64bit) between 32 and 64 bit
methods. Why write two implementations, when the compiler can use the
actual type definition immediately?

DWORD will be replaced by cUInt32 (or equivalent - what?), as far as
this type is used outside dedicated MSWINDOWS code.

The 16 bit word datatype IMO should not be used in 32 bit code, unless
where required in datastructures with a fixed layout.

Similar considerations and decisions will be required during porting, I
only presented these examples as a concrete base for a general
discussion.


4) Exceptions, Error Codes etc.
IMO it would be sufficient to use one general exception class for the
de/compression errors. An application cannot draw any advantage from
many specialized exception classes, and exception handlers inside a
specific class can use the class specific error code in the exception
object.

For the same reasons I think that public error codes only should be
specified for those error conditions that can or must be handled in some
specific way. These common codes then should be used by all
de/compressor classes.

DoDi


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Optimization error causes pyacc and plex to fail

2005-01-02 Thread Florian Klaempfl
Jonas Maebe wrote:
On 1 jan 2005, at 19:49, [EMAIL PROTECTED] wrote:
Can't seem to get bug submission to work so I'm sending this here.
The 1.9.x distributed binaries of plex and pyacc both fail, as well as 
any created from a 1.9.5 source snapshot. plex ends normally but only 
creates 2 states. pyacc fails with a RTE 216 on a move in procedure 
setunion of yaccbase. The makefile compiles these programs with the 
-OG2p3 option. Changing this to either -Og2p3 or -OG1p3 and they both 
work correctly. I am using unmodified versions of both programs so am 
only attaching the output of each scenario. Feel free to contact me if 
you need anything else.

Could you try again with the 1.9.6 release? Several optimizer bugs have 
been fixed this week. I can't test since I don't have any yacc/lex 
grammar available.
h2pas?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Optimization error causes pyacc and plex to fail

2005-01-02 Thread Marco van de Voort
 On 1 jan 2005, at 19:49, [EMAIL PROTECTED] wrote:
  Can't seem to get bug submission to work so I'm sending this here.
  The 1.9.x distributed binaries of plex and pyacc both fail, as well as 
  any created from a 1.9.5 source snapshot. plex ends normally but only 
  creates 2 states. pyacc fails with a RTE 216 on a move in procedure 
  setunion of yaccbase. The makefile compiles these programs with the 
  -OG2p3 option. Changing this to either -Og2p3 or -OG1p3 and they both 
  work correctly. I am using unmodified versions of both programs so am 
  only attaching the output of each scenario. Feel free to contact me if 
  you need anything else.
 
 Could you try again with the 1.9.6 release? Several optimizer bugs have 
 been fixed this week. I can't test since I don't have any yacc/lex 
 grammar available.

(today's 1.9.7)

-bash-2.05b$ touch h2pas.y
There is mail for you!
-bash-2.05b$ gmake
/home/marcov/bin/pyacc h2pas.y
TP Yacc Version 4.1a [April 2000], Copyright (c) 1990-2000 Albert Graef
parse ... sort ... closures ... Runtime error 216 at $08051474
  $08051474  MOVE,  line 76 of /home2/marcov/cvs/devel/fpc/rtl/i386/i386.inc
  $0804F0A1  SETUNION,  line 349 of yaccbase.pas
  $08049167  CLOSURES,  line 94 of yaccclos.pas
  $0804E55A  GENERATE_PARSER,  line 580 of yaccsem.pas
  $08062EA4  YYACTION,  line 250 of pyacc.pas
  $08062A9A  YYPARSE,  line 2079 of pyacc.pas
  $0806494A  main,  line 2479 of pyacc.pas

gmake: *** [h2pas.pas] Error 216
-bash-2.05b$ touch scan.l
-bash-2.05b$ gmake
/home/marcov/bin/plex scan.l
TP Lex Version 4.1a [April 2000], Copyright (c) 1990-2000 Albert Graef
parse ... DFA construction ... code generation ... DONE
839 lines, 88 rules, 555/1200 p, 2/600 s, 0/1200 t.
/home/marcov/bin/ppc386 -Sg -Fu../../rtl/units/i386-freebsd -FE. 
-FUunits/i386-freebsd -di386 h2pas.pas
Free Pascal Compiler version 1.9.7 [2005/01/02] for i386
Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: FreeBSD/ELF for i386
Compiling h2pas.pas
Compiling scan.pas
scan.pas(232,6) Note: Local variable i not used
scan.pas(943,25) Error: High range limit  low range limit
scan.pas(943,25) Error: Upper bound of range is less than lower bound
scan.pas(946,2) Error: Illegal expression
scan.pas(946,2) Error: Illegal expression
scan.pas(946,2) Fatal: Syntax error, ) expected but ; found
gmake: *** [h2pas] Error 1
-bash-2.05b$

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] compiler bug?

2005-01-02 Thread Michael Van Canneyt

No offence meant but,

Can this thread (see subject) please be stopped ?
It is no longer interesting for the rest of us,
and threatens to lead to a flame war.
I'm sure no-one is interested in that either.

Michael.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Interface to compressed files and archives

2005-01-02 Thread Vinzent Hoefler
On Friday 31 December 2004 14:24, [EMAIL PROTECTED] wrote:

 Normally one never uses a fully qualified identifier.

So I'm not normal. ;) I *always* use them. Makes life easier.

 Only when a possible name conflict exists, which
 - Should be very rare, and avoided in the first place.

IBTD. I even often use the same names for same things, but in different 
units (like Open/Close, ...). I don't see any reason to not use the 
unit-name for identifiers. This also avoids C-like prefixes to each 
name. One usually does the same with OOP techniques where each 
constructor is called Init or Create. ;-)

And BTW, it is not very long ago that this actually saved me from 
intermixing Objects.NewStr with SysUtils.NewStr.


Vinzent.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Portability Standards

2005-01-02 Thread Tomas Hajny
On Sun, 2 Jan 2005 23:35:10 +0100 (Romance Standard Time), Michael Van Canneyt
wrote
 On Sun, 2 Jan 2005, DrDiettrich wrote:
 
  Michael Van Canneyt wrote:
 .
 .
  2) File Restructuring
  I've separated the spaghetti code in AbUtils.pas into distinct MSWINDOWS
  and UNIX sections, each containing complete procedures. These sections
  could be moved into dedicated OS specific include files - what's the
  preferred way?
 
 {$ifndef unix}
 {$i abiuwin.inc} // more to follow later: e.g. Mac OS, Netware etc.
 {$else}
 {$i abiulin.inc}
 {$endif}

There's at least one (IMHO not worse at least) alternative to that (already
used in FPC itself among others) - keep the include file name the same, place
it in separate directories for different targets (like UNIX, WIN32, etc.) and
provide the right paths using a Makefile (see e.g. fcl/Makefile.fpc + Makefile
in our source tree). The advantage of this approach is that you don't need any
ifdefs at all (especially when there are more targets supported it could get
somewhat messy).

Tomas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel