I found two minor problems (so far) on Fedora Core 4 (current svn):
1. The "Copyright:" tag must be "License:" in the fpc.spec file. (Apparently "Copyright:" has been deprecated for a while).
2. The samplecfg script fails, probably because the upgrade to gcc 4 has changed the output of gcc -v

The attached patch fixed both these for me.
Colin

Take a look here: www.cnoc.nl/fpc

I'm trying to get these packages into fedora-extras. If you have some comments, they are welcome...

I gave it a quick try, and it seems basically ok for me. Point 2 is still needs fixing as per my patch. Having said that, maybe the samplecfg stuff should be run at rpm build time - the result will be fixed for a given
build. This means the standard rpm approach of marking the fpc.cfg file as a configuration file (and thus potentially preserved across upgrades) can be taken. It would also loose the output from the postinstall rpm script (I think the rpm standard says these scripts should have no output.)

Is the idea that the fpc.spec file then becomes the standard for fpc?

Colin

I will be working on a feature or a program that outputs post-processed code when using macros.

Just to verify that this feature hasn't already been implemented or a program hasn't already been created by someone?

My ideas for a compiler feature or program:
-If the -Sm option is on, and a user specifies some define macros -and if a macro dump compiler option is set,
the compiler or program runs through the code, replaces all macros, and dumps the processed source code into files into some directory for the user. The source code that is dumped for him, is the post-processed code. i.e. the user will now get to see source code after his macros were dropped in place.

Basically, a feature to create unit files with macros shown directly in place. Is there already a feature or program that does this? I don't want to reinvent the wheel.

I started something in the past, see parser.pas and search for PREPROCWRITE. But the problem is that already too much information is lost in the scanner.

It is easier to write an external preprocessor writer instead of extending the compiler. The scanner in the compiler is focussed on speed for reading. Not to keep information like comments and layouts.

L505 wrote

Now the question I have is: does Pascal already have a function like this?

Yes: readln(f)

Jonas

SeekEoln(Text)

While working on some functions in the strwrap1.zip package I am upgrading, I have found the need for a new low level function I think.

Something similar to
ReadLn(F,Line)

This one is slightly different:
PassLn(F)

Instead of reading the line, copying the text the line into a Line var, the PassLn function just passes by the line and sets the pointer up at the beginning of the next line. No copying of the string. This way you can skip copying the text of the line, and move on to the next one directly.

I have made a whole bunch of patches to my Fpc sources and recompiled a lot of units, and have got a PassLn function working today :) All the error messages and some low level units needed slight modification (i.e. _readln_passln_writeln instead of _readln_writeln, fpc_PassLn_End addition, etc.). But it wasn't so bad really.

Now the question I have is: does Pascal already have a function like this? I definitely need a function like this for some ideas I have with strwrap1 package.

If there is already a way to do this, at least I know my way around the FPC low level string sources a bit more now.

| SeekEoln(Text)

Ahh, so would this offer exactly the same functionality as Jonas' suggestion?

| readln(f)
|
|

Or would the "skips spaces" I read about in seekEoLn offer different different behavior?

Lars

|
| > Now the question I have is: does Pascal already have a function | > like this?
|
| Yes: readln(f)
|
|
| Jonas
|

Wonderful..

Hmm, how do we add this to the FPDOC help safely, since it isn't doesn't seem to be created automatically by FPDOC? Maybe we could just make another example demo for people

i.e. online fpdoc help just shows readln(args) but not readln(f)