Sign in Join

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

Mailing lists / lazarus / 2002-02

kylix 2 (OE) -> FSF components-is it possible?

7 messages · 6 people ·

Reply by email Subscribe to this list Your subscription

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

AgentOrange
to Mattias Gaertner: The question is simple: Where should I put the search path for Sources? Don't mix up…

License of kylix 2 (OE) prohibits using its IDE in competing projects (except plugins for Kylix or smth. so, I am not a loyer and English is not my native language). But it is possible to develop a component (for example, now I am developing rich text (not rtf) control) and publish it as a GPL. Is it possible to me (or only for someone else) take this GPL-ed control and ajust to another delphi-like project? (lazarus or so). As for lazarus, I think, gtk is not a good idea. Idea of fpgui was well, but it died.

Reply by email

Marco van de Voort
to Mattias Gaertner: The question is simple: Where should I put the search path for Sources? Don't mix up…
Show quoted text 11 lines
Where should I put the search path for Sources? Don't mix up Source Path with Unit Path. The unit path is used by the compiler to search for .pp/.pas/.ppu/.ppw files. For example an LCL program needs $(LazarusDir)/lcl/units to find the compiled .ppu/.ppw files. The lcl sources are in the $(LazarusDir)/lcl directory, but you will probably never add this path to the unit path. But 'Find Declaration' needs this path to find the sources. That's why the codetools distinguish between Unit Path and Source Path. The Source Path is an extended Unit Path. So, the source path is needed by the codetools, not by the compiler. Hence, it should not be added to the compiler options. Eventually there will be one or two dialogs for all the codetool options. Logically, it should be added there. But I'm not sure, if a user expects this option to be there. Perhaps most users think, that a search path for pascal sources belongs to the search paths in the compiler options. Where should I place the Source Path?

Don't know, but it could also be used for the debugger, which also _needs_ sources, not .ppu's.

Reply by email

Mattias Gaertner

Hi all,

The question is simple:
Where should I put the search path for Sources?

Don't mix up Source Path with Unit Path.
The unit path is used by the compiler to search for .pp/.pas/.ppu/.ppw files. For example an LCL program needs $(LazarusDir)/lcl/units to find the compiled .ppu/.ppw files. The lcl sources are in the $(LazarusDir)/lcl directory, but you will probably never add this path to the unit path. But 'Find Declaration' needs this path to find the sources. That's why the codetools distinguish between Unit Path and Source Path. The Source Path is an extended Unit Path.

So, the source path is needed by the codetools, not by the compiler. Hence, it should not be added to the compiler options. Eventually there will be one or two dialogs for all the codetool options. Logically, it should be added there. But I'm not sure, if a user expects this option to be there. Perhaps most users think, that a search path for pascal sources belongs to the search paths in the compiler options.

Where should I place the Source Path?

Mattias

Reply by email

Satan
to Mattias Gaertner
Show quoted text 16 lines
> Where should I put the search path for Sources? > > Don't mix up Source Path with Unit Path. > The unit path is used by the compiler to search for .pp/.pas/.ppu/.ppw files. > For example an LCL program needs $(LazarusDir)/lcl/units to find the compiled .ppu/.ppw files. The lcl sources are in the $(LazarusDir)/lcl directory, but you will probably never add this path to the unit path. > But 'Find Declaration' needs this path to find the sources. That's why the codetools distinguish between Unit Path and Source Path. The Source Path is an extended Unit Path. > > So, the source path is needed by the codetools, not by the compiler. Hence, it should not be added to the compiler options. Eventually there will be one or two dialogs for all the codetool options. Logically, it should be added there. > But I'm not sure, if a user expects this option to be there. Perhaps most users think, that a search path for pascal sources belongs to the search paths in the compiler options. > > Where should I place the Source Path? Don't know, but it could also be used for the debugger, which also _needs_ sources, not .ppu's.

i think there is a fpc source path to be set where all dirs are set this is no unit path either
so why not just put all dirs/pathes in one dialog? the difference between unit and source path can be mentioned in the help (ahmm... which help?) if the codetools get their own dialogs put it there, but if not...

666

Reply by email

Michael Van Canneyt
to AgentOrange: License of kylix 2 (OE) prohibits using its IDE in competing projects (except plugins for…
AgentOrange wrote
License of kylix 2 (OE) prohibits using its IDE in competing projects (except plugins for Kylix or smth. so, I am not a loyer and English is not my native language). But it is possible to develop a component (for example, now I am developing rich text (not rtf) control) and publish it as a GPL. Is it possible to me (or only for someone else) take this GPL-ed control and ajust to another delphi-like project? (lazarus or so). As for lazarus, I think, gtk is not a good idea. Idea of fpgui was well, but it died.

fpgui hasn't died, it is 'underground' - it won't surface again until it is ready for it.

Michael.

Reply by email

AgentOrange
to Mattias Gaertner: The question is simple: Where should I put the search path for Sources? Don't mix up…

Keith Bowes �����:

Show quoted text 27 lines
----- Original Message ----- From: "AgentOrange" To: Sent: Thursday, February 07, 2002 2:38 AM Subject: [lazarus] kylix 2 (OE) -> FSF components-is it possible? > License of kylix 2 (OE) prohibits using its IDE in competing projects (except plugins for Kylix or smth. so, I am not a loyer and English is not my native language). But it is possible to develop a component (for example, now I am > developing rich text (not rtf) control) and publish it as a GPL. Is it possible to me (or only for someone else) take this GPL-ed control and ajust to another delphi-like project? (lazarus or so). I'm not a student of the legal system either, but it seems to me that a viable loophole would be to develop a component for Lazarus and then port it to Delphi/Kylix (or better yet, design it to work in both, if possible). > As for lazarus, I think, gtk is not a good idea. Idea of fpgui was well, but it died. > Part of what makes Lazarus an interesting project is you can bind it to any API you choose. You're not stuck with whatever the authors choose; you can develop any interface you want if you don't like GTK. But, as I've experienced in trying to develop a native Win32 interface, that's easier said than done.

I saw too. Besides, currently lazarus doesn't support events (except defined in constructors). Fpgui somewhat did.

Reply by email

Keith Bowes
to Mattias Gaertner: The question is simple: Where should I put the search path for Sources? Don't mix up…

----- Original Message -----

Earlier message 29 lines
From: "AgentOrange" To: Sent: Thursday, February 07, 2002 2:38 AM Subject: [lazarus] kylix 2 (OE) -> FSF components-is it possible? > License of kylix 2 (OE) prohibits using its IDE in competing projects (except plugins for Kylix or smth. so, I am not a loyer and English is not my native language). But it is possible to develop a component (for example, now I am > developing rich text (not rtf) control) and publish it as a GPL. Is it possible to me (or only for someone else) take this GPL-ed control and ajust to another delphi-like project? (lazarus or so). I'm not a student of the legal system either, but it seems to me that a viable loophole would be to develop a component for Lazarus and then port it to Delphi/Kylix (or better yet, design it to work in both, if possible). > As for lazarus, I think, gtk is not a good idea. Idea of fpgui was well, but it died. > Part of what makes Lazarus an interesting project is you can bind it to any API you choose. You're not stuck with whatever the authors choose; you can develop any interface you want if you don't like GTK. But, as I've experienced in trying to develop a native Win32 interface, that's easier said than done. Keith

Reply by email