Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2010-08

Re: RTTI unit

21 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Dimitri Smits

Michael, thank you for the reply. It makes a few things a lot clearer for me. I'll comment a bit more below.

----- "Michael Van Canneyt" wrote 17 lines
On Sat, 28 Aug 2010, Dimitri Smits wrote: > What I want to do: > Since Delphi 2010, there is a new unit in the RTL that makes RTTI more of > a breeze. I'd like to port (meaning: compatible interface, fpc > implementation) this unit to fpc-rtl. Initially port over what is there > already. Later maybe include in the compiler stuff like scoped RTTI (not > just published alone) and "customattributes" if there is need for that > level of compatibility. Also, adding more methods on the current > interface is possible too. It is more than just a readable substitute for > TypInfo. Well, the compiler doesn't support custom attributes.

I know, neither does it support RTTI-scoping (only published members of a class, and other types are 'public') or run-time unit per package registration or ...

Like I said: first implement what is there and can be ported to fpc. That way I do not have to dive into compiler-output and parsing (for now). Later on, it can be expanded with those features that DO get implemented or not if they'll never be. After initial porting, I might extend the interfaces with a few methods (e.g.: getters+setters with AsString+AsInteger+As... etc).

But first: port what is there.

Show quoted text 7 lines
> > For this I'd like to know a few things: > - First off: would this kind of thing even be considered for inclusion? Yes. Any unit to increase Delphi compatibility is worth of inclusion.

good to know. to be placed next to types unit in objpas, I presume.

> - How to get it into repository/feedback from core? (through feature request with attachment in mantis?) I'll handle that; Just post it on mantis, I'll look into it.

attach the unit, or in patch form?

Show quoted text 5 lines
> - Codestyle conventions for fpc-code? (including licence-header etc) Modified LGPL header (see any rtl file). Code style: follow the Borland style guide.

that header, with your name & Florian or mine or 3? :-)

Show quoted text 5 lines
> - Is there (besides System, SysUtils, Types and the Variant-units) another place to look for RTTI-types? Not sure I know what you mean by this ?

Is there another unit other than those that contains structures & defs mapping to what the compiler generates? (like ptypeinfo, but also for punittype, or packages)

anything I've missed regarding lowlevel info on types & language constructs

Show quoted text 6 lines
> - Where do I need to take care off (how to include it in rtl package, ..., unit-dependencies )? Nothing. I'll take care of that, you just write the code.

what i meant was: don't use generic types like fpglist and/or consorts that are not in the rtl package. (what files can I check to see what is included in the rtl so I don't accidentally make cyclic dependencies.

Show quoted text 9 lines
> - I've read somewhere that nothing gets included if no unit-tests are > - provided. Is this using fpcunit? Any pointers on the testingsystem, > - do's and don'ts are welcome. You can use fpcunit; there are sample tests in the fcl-fpcunit directory.

to be placed under what dir? fpcunit would have been my choice nevertheless. :-)

Show quoted text 8 lines
All other daily test programs use a different mechanism: they must return a zero exit code. Nonzero exit code means that there is an error. You're free to choose one over the other; Personally, I favour fpc-unit style. I find it works most easily, definitely if you use Lazarus.

so, lpi files and the like are acceptable in fpc?

Show quoted text 8 lines
> Since I work on win32 (only), I'm not that familiar with makefiles. So, if > I need to add anything to makefiles or copy+edit another makefile, please > redirect me to more information. (mainly for testing-app, I guess) Let me handle that. Focus on the code.

will do. Have to start, and probably will go through a few iterations before I post it in mantis (also, when time permits). And even then it might be something to discuss first and take a few posts to get it "feature complete".

if that's allright by you ;-)

kind regards,
Dimitri Smits

Reply by email

Michael Van Canneyt
to Dimitri Smits
Dimitri Smits wrote 11 lines
Michael, thank you for the reply. It makes a few things a lot clearer for me. I'll comment a bit more below. >> >> For this I'd like to know a few things: >> - First off: would this kind of thing even be considered for > inclusion? > > Yes. Any unit to increase Delphi compatibility is worth of inclusion. good to know. to be placed next to types unit in objpas, I presume.

Yes.

Show quoted text 7 lines
>> - How to get it into repository/feedback from core? (through feature > request with attachment in mantis?) > > I'll handle that; Just post it on mantis, I'll look into it. attach the unit, or in patch form?

Attach the unit to your mantis bug report.

Show quoted text 8 lines
>> - Codestyle conventions for fpc-code? (including licence-header > etc) > > Modified LGPL header (see any rtl file). > Code style: follow the Borland style guide. that header, with your name & Florian or mine or 3? :-)

Just put "FPC team" or so.

Show quoted text 12 lines
> >> - Is there (besides System, SysUtils, Types and the Variant-units) > another place to look for RTTI-types? > > Not sure I know what you mean by this ? Is there another unit other than those that contains structures & defs mapping to what the compiler generates? (like ptypeinfo, but also for punittype, or packages) anything I've missed regarding lowlevel info on types & language constructs

There is nothing; the typeinfo unit contains most info apart from the compiler sources.

Show quoted text 11 lines
> >> - Where do I need to take care off (how to include it in rtl > package, ..., unit-dependencies )? > > Nothing. I'll take care of that, you just write the code. > what i meant was: don't use generic types like fpglist and/or consorts that are not in the rtl package. (what files can I check to see what is included in the rtl so I don't accidentally make cyclic dependencies.

No generics, please. Generics are highly beta.
Apart from that, I don't think there are any caveats.

Show quoted text 12 lines
>> - I've read somewhere that nothing gets included if no unit-tests > are >> - provided. Is this using fpcunit? Any pointers on the > testingsystem, >> - do's and don'ts are welcome. > > You can use fpcunit; there are sample tests in the fcl-fpcunit > directory. > to be placed under what dir? fpcunit would have been my choice nevertheless. :-)

We'll see.

Show quoted text 11 lines
> All other daily test programs use a different mechanism: they must > return > a zero exit code. Nonzero exit code means that there is an error. > > You're free to choose one over the other; Personally, I favour > fpc-unit style. > I find it works most easily, definitely if you use Lazarus. > so, lpi files and the like are acceptable in fpc?

Insofar as they contain only non-visual code. No dependency on the LCL. The .lpi file should just enumerate the dependencies of your pogram; session info should be in a separate file, which is not committed to SVN.

Show quoted text 16 lines
>> Since I work on win32 (only), I'm not that familiar with makefiles. > So, if >> I need to add anything to makefiles or copy+edit another makefile, > please >> redirect me to more information. (mainly for testing-app, I guess) > > Let me handle that. Focus on the code. > will do. Have to start, and probably will go through a few iterations before I post it in mantis (also, when time permits). And even then it might be something to discuss first and take a few posts to get it "feature complete". if that's allright by you ;-)

Of course.

Michael.

Reply by email

Graeme Geldenhuys
to Dimitri Smits: Michael, thank you for the reply. It makes a few things a lot clearer for me. I'll…
Dimitri Smits wrote 5 lines
> You're free to choose one over the other; Personally, I favour > fpc-unit style. > I find it works most easily, definitely if you use Lazarus. so, lpi files and the like are acceptable in fpc?

I think he means that there is a GUI unit test runner for fpcunit included with Lazarus (and fpGUI by the way). As for the .lpi files, I don't think those belong in the FPC project source. FPC and Lazarus are separate projects, not everybody using FPC use Lazarus. After all, all IDE's worth using, should have a feature to create a IDE Project File from a program unit. I know Lazarus IDE and MSEide can do this - so that again indicates that a specific IDE project file doesn't need to be in the FPC source code.

Regards,   - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/

Reply by email

Sven Barth
to Graeme Geldenhuys
Graeme Geldenhuys wrote 17 lines
On 29 August 2010 15:32, Dimitri Smits wrote: >> You're free to choose one over the other; Personally, I favour >> fpc-unit style. >> I find it works most easily, definitely if you use Lazarus. > > so, lpi files and the like are acceptable in fpc? I think he means that there is a GUI unit test runner for fpcunit included with Lazarus (and fpGUI by the way). As for the .lpi files, I don't think those belong in the FPC project source. FPC and Lazarus are separate projects, not everybody using FPC use Lazarus. After all, all IDE's worth using, should have a feature to create a IDE Project File from a program unit. I know Lazarus IDE and MSEide can do this - so that again indicates that a specific IDE project file doesn't need to be in the FPC source code.

LPI files are already included with FPC. E.g. for the compiler itself (so you don't need to add all search paths manually...) and for the Win32 RTL (excluding the system unit).
No autogenerate system will add the correct searchpaths by itself, so some file must be included for that system. So why not use the LPI file...

Regards,
Sven

Reply by email

Graeme Geldenhuys
to Sven Barth

Op 2010-08-30 09:45, Sven Barth het geskryf:

LPI files are already included with FPC. E.g. for the compiler itself (so you don't need to add all search paths manually...) and for the Win32 RTL (excluding the system unit).

FPC has support for external config files which could handle this for you. In the fpGUI project I have many such config files called "extrafpc.cfg". Each line of that config file is a compiler parameter, you can use IFDEF functionality and even FPC's macros. See the example below.

This is a more advanced example than usual, but it shows IFDEF usage and FPC macros like $fpctarget.

To use this from the command line:
fpc -dX11 @extrafpc.cfg <program_unit.pas>

-----------------------------
# * * * I M P O R T A N T * * *
# You need to specify which backend you are compiling for. This # will be the only extra compiler parameter you use. #
# Your options are:
# -dX11 for X11 support (eg: Linux or FreeBSD) # -dGDI for Windows GDI support
# -dCarbon for Mac OS X Carbon support.

# Slashes are also allowed under Dos or Windows
# search path for include files
-Fi.
-Ficorelib
#IFDEF X11
-Ficorelib/x11/
#ENDIF
#IFDEF GDI
-Ficorelib/gdi/
#ENDIF

# searchpath for units and other system dependent things -Fu.
-Fucorelib/
#IFDEF X11
#WRITE Compiling X11 CoreLib
-Fucorelib/x11/
#ENDIF
#IFDEF GDI
#WRITE Compiling GDI CoreLib
-Fucorelib/gdi/
#ENDIF
#IFDEF Carbon
#WRITE Compiling Carbon CoreLib
-Fucorelib/carbon/
#ENDIF
-Fugui/
-Fugui/db/

# Unit output path
-FU../lib/$fpctarget/
-----------------------------

So again, no need to include some IDE specific files, not related to the FPC project or sources. Otherwise we can start adding FP (text) IDE, MSEide, fpGUI IDE, Syn Editor project files etc.... Where does it end?

In addition to such external config files, FPC also includes the fpcmake.pas functionality. This again allows it to setup search paths etc. for a project, even the compiler itself.

BTW:
Lazarus IDE can read such external config files too, so again it is very easy to setup a Lazarus project using a program unit, and simply telling it to read the extrafpc.cfg file for search path information. With MSEide you can do the same.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Sven Barth
to Graeme Geldenhuys
Graeme Geldenhuys wrote 10 lines
Op 2010-08-30 09:45, Sven Barth het geskryf: > LPI files are already included with FPC. E.g. for the compiler itself > (so you don't need to add all search paths manually...) and for the > Win32 RTL (excluding the system unit). FPC has support for external config files which could handle this for you. In the fpGUI project I have many such config files called "extrafpc.cfg". Each line of that config file is a compiler parameter, you can use IFDEF functionality and even FPC's macros. See the example below.

[...]

Show quoted text 10 lines
In addition to such external config files, FPC also includes the fpcmake.pas functionality. This again allows it to setup search paths etc. for a project, even the compiler itself. BTW: Lazarus IDE can read such external config files too, so again it is very easy to setup a Lazarus project using a program unit, and simply telling it to read the extrafpc.cfg file for search path information. With MSEide you can do the same.

I'll find a reason to include *.lpi files... I'll find one... I'll find one... damn... I failed :P

It might be practical to extend Lazarus (and maybe the other IDEs as well) to auto search for an extrafpc.cfg in the same dir as the program file so that it is used automatically.

Does identifier search/completion work in Lazarus if you use a extrafpc.cfg to define search paths?

Another possibility would be to extend fpcmake to generate different IDE project files besides the Makefile as well.

Regards,
Sven

Reply by email

Michael Van Canneyt
to Sven Barth
Sven Barth wrote 31 lines
Am 30.08.2010 10:15, schrieb Graeme Geldenhuys: > Op 2010-08-30 09:45, Sven Barth het geskryf: >> LPI files are already included with FPC. E.g. for the compiler itself >> (so you don't need to add all search paths manually...) and for the >> Win32 RTL (excluding the system unit). > > FPC has support for external config files which could handle this for you. > In the fpGUI project I have many such config files called "extrafpc.cfg". > Each line of that config file is a compiler parameter, you can use IFDEF > functionality and even FPC's macros. See the example below. > [...] > In addition to such external config files, FPC also includes the > fpcmake.pas functionality. This again allows it to setup search paths etc. > for a project, even the compiler itself. > > > BTW: > Lazarus IDE can read such external config files too, so again it is very > easy to setup a Lazarus project using a program unit, and simply telling it > to read the extrafpc.cfg file for search path information. With MSEide you > can do the same. I'll find a reason to include *.lpi files... I'll find one... I'll find one... damn... I failed :P It might be practical to extend Lazarus (and maybe the other IDEs as well) to auto search for an extrafpc.cfg in the same dir as the program file so that it is used automatically.

That presupposes that the use of extrafpc.cfg is a common thing. It is not, this is something that Graeme uses.

Show quoted text 5 lines
Does identifier search/completion work in Lazarus if you use a extrafpc.cfg to define search paths? Another possibility would be to extend fpcmake to generate different IDE project files besides the Makefile as well.

fpcmake will be phased out, it's a bad idea to extend it.

Michael.

Reply by email

Sven Barth
to Michael Van Canneyt
Michael Van Canneyt wrote 7 lines
> It might be practical to extend Lazarus (and maybe the other IDEs as > well) to auto search for an extrafpc.cfg in the same dir as the > program file so that it is used automatically. That presupposes that the use of extrafpc.cfg is a common thing. It is not, this is something that Graeme uses.

But it's a format that is understood by the compiler and does not rely on an "external" IDE. May be it should be made common instead of IDE specific project files.

Don't get me wrong here: I am not against the usage of LPI files in the FPC sources (because I'm using Lazarus), but Graeme raised a valid point: not everyone uses Lazarus and thus we might think about using a file format that can be used by more IDEs than just Lazarus. The config file might be such a format, but it depends on the support by the involved IDEs (FP IDE, Lazarus, MSEide).

Show quoted text 7 lines
> Does identifier search/completion work in Lazarus if you use a > extrafpc.cfg to define search paths? > > Another possibility would be to extend fpcmake to generate different > IDE project files besides the Makefile as well. fpcmake will be phased out, it's a bad idea to extend it.

Right you are.

What about fppkg then? Would it be a feasible idea or a valid task to let it create project files for different IDEs?

Regards,
Sven

Reply by email

Graeme Geldenhuys
to Sven Barth: [...] I'll find a reason to include *.lpi files... I'll find one... I'll find one...…

Op 2010-08-30 10:43, Sven Barth het geskryf:

It might be practical to extend Lazarus (and maybe the other IDEs as well) to auto search for an extrafpc.cfg in the same dir as the program file so that it is used automatically.

I think I can speak for a few developers, that such automations can just cause more frustration than good. I personally hate software that tries to be too clever. Lazarus IDE is already on the borderline of that.

Does identifier search/completion work in Lazarus if you use a extrafpc.cfg to define search paths?

I think it does. Either way, when it comes to FPC sources, Lazarus IDE has a config option that you use to tell it where FPC sources are located, so it already parsed & cached that information for auto-completion and code navigation.

Another possibility would be to extend fpcmake to generate different IDE project files besides the Makefile as well.

I don't think this is viable:

* There are just too many programmer editors or IDE's that could be used, so this will be a never ending job.

* fpcmake is "apparently" being phased out - although a oil tanker moves faster that that. :)
NOTE: A correction to my previous message. I meant to type fpmake and _not_ fpcmake. fpmake is apparently the replacement to fpcmake.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt: That presupposes that the use of extrafpc.cfg is a common thing. It is not, this is…

Op 2010-08-30 11:23, Michael Van Canneyt het geskryf:

That presupposes that the use of extrafpc.cfg is a common thing. It is not, this is something that Graeme uses.

FPC has had support for such extra config files since I started using FPC (+-5 years ago). It's also a documented feature, so it's not like I'm using some corner case hack - it's a legit feature of FPC, and a very handy one.

Secondly, Lazarus IDE has also had support for reading such extra config files since I started using Lazarus (also 5+ years ago).

This FPC feature has been in existence for a very long time.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys
Graeme Geldenhuys wrote 13 lines
Op 2010-08-30 11:23, Michael Van Canneyt het geskryf: > > That presupposes that the use of extrafpc.cfg is a common thing. > It is not, this is something that Graeme uses. FPC has had support for such extra config files since I started using FPC (+-5 years ago). It's also a documented feature, so it's not like I'm using some corner case hack - it's a legit feature of FPC, and a very handy one. Secondly, Lazarus IDE has also had support for reading such extra config files since I started using Lazarus (also 5+ years ago). This FPC feature has been in existence for a very long time.

I know that, but that is not what I meant.

What I meant is that you use the config file feature consistently in the same way, whereas other people don't. Therefor, basing a feature on the way you work is no better than including a .lpi file (which happens to be the way I work).

What is more, the cfg file does not contain any project information: what files are part of the project.

Michael.

Reply by email

Graeme Geldenhuys
to Sven Barth: But it's a format that is understood by the compiler and does not rely on an "external"…

Op 2010-08-30 11:53, Sven Barth het geskryf:

file might be such a format, but it depends on the support by the involved IDEs (FP IDE, Lazarus, MSEide).

As far as I know, all IDE's and programmer editors have some option to pass settings directly to the compiler as a parameter. Simply typing in "@extrafpc.cfg" should do the trick in all cases.

ps:
extrafpc.cfg is not a hard-coded file name, you can use any file name. For example, in Lazarus IDE, I use different .cfg file for various "build modes" (eg: debug build, release build, verbose loggging etc.)

No need to fiddle with compiler setting is various dialogs and tabs, simply toggle between the .cfg files.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Michael Van Canneyt
to Sven Barth: But it's a format that is understood by the compiler and does not rely on an "external"…
Sven Barth wrote 19 lines
Am 30.08.2010 11:23, schrieb Michael Van Canneyt: >> It might be practical to extend Lazarus (and maybe the other IDEs as >> well) to auto search for an extrafpc.cfg in the same dir as the >> program file so that it is used automatically. > > That presupposes that the use of extrafpc.cfg is a common thing. It is > not, this is something that Graeme uses. > But it's a format that is understood by the compiler and does not rely on an "external" IDE. May be it should be made common instead of IDE specific project files. Don't get me wrong here: I am not against the usage of LPI files in the FPC sources (because I'm using Lazarus), but Graeme raised a valid point: not everyone uses Lazarus and thus we might think about using a file format that can be used by more IDEs than just Lazarus. The config file might be such a format, but it depends on the support by the involved IDEs (FP IDE, Lazarus, MSEide).

It is IMHO not suitable, because it does not contain information on the actual project files. It's just suitable to guide compilation.

Show quoted text 12 lines
>> Does identifier search/completion work in Lazarus if you use a >> extrafpc.cfg to define search paths? >> >> Another possibility would be to extend fpcmake to generate different >> IDE project files besides the Makefile as well. > > fpcmake will be phased out, it's a bad idea to extend it. Right you are. What about fppkg then? Would it be a feasible idea or a valid task to let it create project files for different IDEs?

Definitely not, that would be the opposite of what we try to achieve: get fppkg support into the IDEs.

So in fact the solution is simple; provide a fpmake.pp file, and let the IDE's figure it out from there.

We'll take that as a rule for contributions from now on :) I'll discuss this in the FPC core list.

Michael.

Reply by email

Sven Barth
to Graeme Geldenhuys: Op 2010-08-30 10:43, Sven Barth het geskryf: I think I can speak for a few developers,…
Graeme Geldenhuys wrote 7 lines
> Does identifier search/completion work in Lazarus if you use a > extrafpc.cfg to define search paths? I think it does. Either way, when it comes to FPC sources, Lazarus IDE has a config option that you use to tell it where FPC sources are located, so it already parsed& cached that information for auto-completion and code navigation.

No, that is not working that way. I set my FPC source directory to the sources of the latest release, but I'm playing around with the trunk compiler (read as: building the compiler from the IDE). So I need the search paths of the compiler subdirectories and I don't want to add them manually if some file in the compiler dir already contains them.

Regards,
Sven

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt: I know that, but that is not what I meant. What I meant is that you use the config file…

Op 2010-08-30 12:04, Michael Van Canneyt het geskryf:

same way, whereas other people don't. Therefor, basing a feature on the way you work is no better than including a .lpi file (which happens to be the way I work).

I got introduced to that feature years ago in the mailing list. So it's not just me that uses it that way. Even the standard fpc.cfg generated by FPC uses IFDEF and macros - similar to what I do. So I don't agree that it's as "special feature only Graeme uses".

An least in a pinch, one can compile a new compiler or RTL from the command line with ease. Have various config files to enable/disable debugging, line info etc. Very handy for compiler or RTL or FCL development. Currently Lazarus doesn't have various build modes, but the config files do allow for that.

What is more, the cfg file does not contain any project information: what files are part of the project.

Neither does many of the .lpi files included in FPC sources. :) Most of them only contain the main program unit and maybe one or two other units [see compiler directory]. fpdoc.lpi being the exception. ;-)

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys
Graeme Geldenhuys wrote 9 lines
Op 2010-08-30 12:04, Michael Van Canneyt het geskryf: > same way, whereas other people don't. Therefor, basing a feature on the way > you work is no better than including a .lpi file (which happens to be the > way I work). I got introduced to that feature years ago in the mailing list. So it's not just me that uses it that way. Even the standard fpc.cfg generated by FPC uses IFDEF and macros - similar to what I do. So I don't agree that it's as "special feature only Graeme uses".

As far as I can see, most people just use the fpc provided config file, no extra files like you do.

Show quoted text 7 lines
An least in a pinch, one can compile a new compiler or RTL from the command line with ease. Have various config files to enable/disable debugging, line info etc. Very handy for compiler or RTL or FCL development. Currently Lazarus doesn't have various build modes, but the config files do allow for that.

Totally correct, and I don't dispute that.

Show quoted text 7 lines
> What is more, the cfg file does not contain any project information: what > files are part of the project. Neither does many of the .lpi files included in FPC sources. :) Most of them only contain the main program unit and maybe one or two other units [see compiler directory]. fpdoc.lpi being the exception. ;-)

In short, we can drop the matter.

People can submit whatever they like; the FPC team member will decide what gets commited and what not.

Michael.

Reply by email

Sven Barth
to Graeme Geldenhuys
Graeme Geldenhuys wrote 6 lines
Op 2010-08-30 12:16, Sven Barth het geskryf: > > No, that is not working that way. I set my FPC source directory to the > sources of the latest release, but I'm playing around with the trunk Then file a Lazarus IDE bug report.

Heh? I think you misunderstood me here.

I'm setting the FPC source directory to the 2.4.0 sources, because that's the main compiler I'm using.
When I work with in the trunk compiler I compile it inside the IDE using the 2.4.0 RTL. And the search paths of the compilers LPI file are pointing to the relative subdirectories of the compiler.

So what I'm trying to tell you here is this: I can't use Lazarus' FPC source cache, because that are different units (trunk vs. 2.4.0). Also I think that Lazarus parses only RTL and Packages units and not the compiler ones.

Is it more clear now?

Regards,
Sven

Reply by email

Graeme Geldenhuys
to Sven Barth

Op 2010-08-30 13:32, Sven Barth het geskryf:

Is it more clear now?

I understand that, but you still will have to take it up with the Lazarus developers. eg: if you want to navigate the compiler project (like you would do with any other of your projects), and you are using a extrafpc.cfg file, I gather you would like Lazarus IDE to read out the path information inside the extrafpc.cfg file (if they exist), and add those to the search path cached in Lazarus IDE - so you can do code navigation (ctrl+left_click on units or types) without specifying search paths in the "Project > Compiler Options > Paths" dialog.

I understood that you tried code navigation and Lazarus couldn't find code specified in the paths inside the extrafpc.cfg file. If this is indeed the case, then report a bug or feature request, so Lazarus could read search paths from the extrafpc.cfg file.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Sven Barth
to Graeme Geldenhuys
Graeme Geldenhuys wrote
I understood that you tried code navigation and Lazarus couldn't find code specified in the paths inside the extrafpc.cfg file. If this is indeed the case, then report a bug or feature request, so Lazarus could read search paths from the extrafpc.cfg file.

The point is that I didn't tried it. I asked you (and the rest of the list) whether this works, so that using and including a extra config file would be useful in the IDE as well. You interpreted to much into my mails :P

Regards,
Sven

Reply by email

Graeme Geldenhuys
to Sven Barth

Op 2010-08-30 14:27, Sven Barth het geskryf:

The point is that I didn't tried it. I asked you (and the rest of the

No need to guess any more. I just tried, and the answer is NO, Lazarus does not read the path information from the extra config file, so code navigation is not possible outside the current directory. But compiling IS possible.

Here is the x86_64 config file I created. Then started a new project based on pp.pas unit, and added x86_64_settings.cfg as extra compiler options file.

------------[ x86_64_settings.cfg ]----------------- -g
-gl
-O1
-dx86_64
-Fux86_64
-Fux86
-Fusystems
-Fix86_64
-FUx86_64/lazbuild/
-----------------[ end ]----------------------------

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email