Re: [Lazarus] Compile project release with LCL custom optimization
On Sun, Apr 14, 2013 at 8:58 AM, Martin Schreiber mse00...@gmail.comwrote: On Saturday 13 April 2013 21:30:17 Graeme Geldenhuys wrote: On 2013-04-13 20:05, Zaher Dirkey wrote: Not worked for me, i Added $(ProjectOpts) to custom options in SynEdit package (same with my packages but i will take SynEdit as example) What i have I Have 2 build mode (Debug, Release) I use lots of build modes too... like I said, the Lazarus Package idea was more problems than anything else. Now I just define all source paths as needed. Hehe. :-) http://article.gmane.org/gmane.comp.ide.mseide.user/18779 ;-) What is B,M,1,2,..6, is it Build Modes also? -- I am using last revision of Lazarus, FPC 2.6 on Windows XP SP3 Best Regards Zaher Dirkey -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Runtime package (manual compilation only) forced to re-compile by a design time dependant package?
On 14/04/13 01:24, Mattias Gaertner wrote: On Sat, 13 Apr 2013 22:27:11 +0300 patspiper patspi...@gmail.com wrote: [...] In what needs building (with the design package selected), the runtime package is marked as No build needed. Nevertheless, compiling the design time package tries to compile the runtime units. It turned out that the design time package had a other units path that included one unit of the runtime package. I know this is a bad practice, but does it fully explain the observed behaviour? I realise now why they shared the same path, but I am not sure if this is right or wrong. The registration unit of the design time package is in the same folder with the runtime units. Should it be placed in a separate folder? Yes. Packages should not share sources (.pas files). Otherwise the compiler will happily recompile them. If you must share sources, you should add -Ur. 1- So sharing Other Units (-Fu) path causes units to recompile. Is there any other cause that can trigger an unnecessary recompilation? 2- On the other hand, What Needs Building/Lazarus IDE shows that the IDE does not need rebuilding (I changed the IDE build profile): Target: Lazarus IDE No build needed. --- ? File: ../lazarus-svn/ despite that the FCL needs it: Target: FCL 1.0.1 Clean build needed. --- ?? File: /home/me/Programs/lazarus/lazarus-svn/packager/registration/fcl.lpk Note: Compiler parameters changed: Old= Now= State file=/home/me/Programs/lazarus/lazarus-svn/packager/units/i386-linux/FCL.compiled 3- As shown above, FCL's Old and New compiler parameters are empty despite the change in the IDE profile. Should that be the case? Thanks, Stephano -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
On Sat, 13 Apr 2013 19:05:51 -0400 Anthony Walter sys...@gmail.com wrote: Because in theory you should get code insight when you type Identified(dot). From a style perspective I also tend to avoid underscores in my own identifiers. I reserve underscores for methods you normally shouldn't call (_AddRef), or for imported C code (MAX_PATH, type_). Also, I am sure you know dotted unit namespaces are an addition to Free Pascal. They are familiar to C#/Java people, and probably look better (style-wise) to them. In short words: aesthetic reasons and to please people from other languages. Right? If they see dotted unit namespaces in some Free Pascal demos they might be more be tempted to give Free Pascal a look rather than running away (especially if the first thing they see when looking at a Free Pascal example is a list of large identifiers with 2 or more underscores each). What example has a large list of identifiers with many underscores? Why is that better than a large list with many dots? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Runtime package (manual compilation only) forced to re-compile by a design time dependant package?
On Sun, 14 Apr 2013 09:44:08 +0300 patspiper patspi...@gmail.com wrote: [...] 1- So sharing Other Units (-Fu) path causes units to recompile. Is there any other cause that can trigger an unnecessary recompilation? Yes, a bug in the compiler and if the unit does not use a given flag. 2- On the other hand, What Needs Building/Lazarus IDE shows that the IDE does not need rebuilding (I changed the IDE build profile): Target: Lazarus IDE No build needed. --- ? File: ../lazarus-svn/ The IDE is a special case, because it is only built manually. So I didn't implement the test. That's why it is called IDE internals. It's not for user friendliness. despite that the FCL needs it: Target: FCL 1.0.1 Clean build needed. --- ?? File: /home/me/Programs/lazarus/lazarus-svn/packager/registration/fcl.lpk Note: Compiler parameters changed: Old= Now= State file=/home/me/Programs/lazarus/lazarus-svn/packager/units/i386-linux/FCL.compiled 3- As shown above, FCL's Old and New compiler parameters are empty despite the change in the IDE profile. Should that be the case? No. What is difference between those two build profiles? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Compile project release with LCL custom optimization
On Sunday 14 April 2013 08:42:17 Zaher Dirkey wrote: What is B,M,1,2,..6, is it Build Modes also? The menu items 'Project'-'Make','Build','Make 1','Make 2','Make 3','Make 4'. http://mseide-msegui.sourceforge.net/pics/projectmenu.png Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Runtime package (manual compilation only) forced to re-compile by a design time dependant package?
On 14/04/13 10:08, Mattias Gaertner wrote: On Sun, 14 Apr 2013 09:44:08 +0300 patspiper patspi...@gmail.com wrote: despite that the FCL needs it: Target: FCL 1.0.1 Clean build needed. --- ?? File: /home/me/Programs/lazarus/lazarus-svn/packager/registration/fcl.lpk Note: Compiler parameters changed: Old= Now= State file=/home/me/Programs/lazarus/lazarus-svn/packager/units/i386-linux/FCL.compiled 3- As shown above, FCL's Old and New compiler parameters are empty despite the change in the IDE profile. Should that be the case? No. What is difference between those two build profiles? Debug IDE: -gw -gl -godwarfsets -gh -gt -Co -Cr -Ci -Sa Optimized IDE: -O2 -g- -Xs While switching IDE build profiles just now, I noticed the following: Target: ibo5xdt_laz 5.2.0.1 Build needed. File: /home/me/Documents/Data/Lazarus/IBO2LazarusConversion/ibo/packages/lazarus/ibo5xdt_laz.lpk Note: State file of FCL 1.0.1 is newer than state file of Package: ibo5xdt_laz 5.2.0.1 FCL 1.0.1=14/04/13 9:44:39 AM Package: ibo5xdt_laz 5.2.0.1=14/04/13 9:31:03 AM The package should not be recompiled under such circumstances, yet it marked as needs rebuilding!? Stephano -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
Normally I don't reply to a technical discussion when a question about a possible bug is posed back with (channels inner nerd) Why would you ever want to do that?... followed up attempts to chastise. But I'll give you some honest answers. In short words: aesthetic reasons and to please people from other languages. Right? No. What example has a large list of identifiers with many underscores? Why is that better than a large list with many dots? It depends. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
On Sun, 14 Apr 2013 09:41:01 +0200 Sven Barth pascaldra...@googlemail.com wrote: On 14.04.2013 00:38, Mattias Gaertner wrote: On Sat, 13 Apr 2013 17:30:15 -0400 Anthony Walter sys...@gmail.com wrote: It would seem that the Lazarus IDE integrated documentation editor fails to work with units which use dotted names. For example: unit MyCompany.Utilities.Text; Can someone verify this for me? I am preparing some OSS pascal packages (a cross platforming gaming library) which use the above pattern for unit organization and was hoping to start writing documentation. I'm curious: why do you use dots instead of for example underscores? Why shouldn't you? Also in difference to underscores each part of the dotted unit name will be a unique symbol. E.g. for a unit name like System.Collection.Generics all three parts will be a symbol so you can't use them in your code (can be considered both an advantage and a disadvantage). Thanks. You are one of the few people who give some arguments beside aesthetic reasons. Also FPC will in the future also provide units with dotted unitnames to increase compatibility with Delphi XE2 and newer. Can you explain or give some link about the rules for dotted unit names FPC will implement? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
On 14.04.2013 09:59, Mattias Gaertner wrote: On Sun, 14 Apr 2013 09:41:01 +0200 Sven Barth pascaldra...@googlemail.com wrote: On 14.04.2013 00:38, Mattias Gaertner wrote: On Sat, 13 Apr 2013 17:30:15 -0400 Anthony Walter sys...@gmail.com wrote: It would seem that the Lazarus IDE integrated documentation editor fails to work with units which use dotted names. For example: unit MyCompany.Utilities.Text; Can someone verify this for me? I am preparing some OSS pascal packages (a cross platforming gaming library) which use the above pattern for unit organization and was hoping to start writing documentation. I'm curious: why do you use dots instead of for example underscores? Why shouldn't you? Also in difference to underscores each part of the dotted unit name will be a unique symbol. E.g. for a unit name like System.Collection.Generics all three parts will be a symbol so you can't use them in your code (can be considered both an advantage and a disadvantage). Thanks. You are one of the few people who give some arguments beside aesthetic reasons. Also FPC will in the future also provide units with dotted unitnames to increase compatibility with Delphi XE2 and newer. Can you explain or give some link about the rules for dotted unit names FPC will implement? It's still a bit in flux and currently only discussed on the core list, but basically the idea is to use Delphi XE2's unit naming scheme at least for the base units (e.g. System.SysUtils.pp or System.Classes.pp) and make these units use String=UnicodeString while the non dotted units (to stay with the example SysUtils.pp and Classes.pp) keep String=AnsiString for backwards compatiblity. I hope that more information can be provided after the compiler Hackathon from 30th May to 2nd June where some of use will try to implement this scheme (and also extend the compiler with a few things for this). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
On Sun, 14 Apr 2013 03:52:46 -0400 Anthony Walter sys...@gmail.com wrote: Normally I don't reply to a technical discussion when a question about a possible bug is posed back with (channels inner nerd) Why would you ever want to do that?... followed up attempts to chastise. But I'll give you some honest answers. The dotted unit name concept is not a simple change. It heavily effects the scope rules and resolving mechanism. There are many other todos, so you have to convince developers, that this feature has no simple workaround and has priority. But maybe you don't need the full dotted unit name concept. Then maybe some half implementations are enough. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
On Sun, 14 Apr 2013 10:12:45 +0200 Sven Barth pascaldra...@googlemail.com wrote: On 14.04.2013 09:59, Mattias Gaertner wrote: On Sun, 14 Apr 2013 09:41:01 +0200 Sven Barth pascaldra...@googlemail.com wrote: On 14.04.2013 00:38, Mattias Gaertner wrote: On Sat, 13 Apr 2013 17:30:15 -0400 Anthony Walter sys...@gmail.com wrote: It would seem that the Lazarus IDE integrated documentation editor fails to work with units which use dotted names. For example: unit MyCompany.Utilities.Text; Can someone verify this for me? I am preparing some OSS pascal packages (a cross platforming gaming library) which use the above pattern for unit organization and was hoping to start writing documentation. I'm curious: why do you use dots instead of for example underscores? Why shouldn't you? Also in difference to underscores each part of the dotted unit name will be a unique symbol. E.g. for a unit name like System.Collection.Generics all three parts will be a symbol so you can't use them in your code (can be considered both an advantage and a disadvantage). Thanks. You are one of the few people who give some arguments beside aesthetic reasons. Also FPC will in the future also provide units with dotted unitnames to increase compatibility with Delphi XE2 and newer. Can you explain or give some link about the rules for dotted unit names FPC will implement? It's still a bit in flux and currently only discussed on the core list, but basically the idea is to use Delphi XE2's unit naming scheme at least for the base units (e.g. System.SysUtils.pp or System.Classes.pp) and make these units use String=UnicodeString while the non dotted units (to stay with the example SysUtils.pp and Classes.pp) keep String=AnsiString for backwards compatiblity. I hope that more information can be provided after the compiler Hackathon from 30th May to 2nd June where some of use will try to implement this scheme (and also extend the compiler with a few things for this). Yes, afair this basic idea was already mentioned on some other list. I meant, can you give me the rules for the dotted unit name scopes that FPC will implement. Like the System.Collection.Generics all three parts will be a symbol so you can't use them in your code. What exactly does that mean? Are there already some documentations, examples, fpc test units? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
On 14.04.2013 10:31, Mattias Gaertner wrote: I meant, can you give me the rules for the dotted unit name scopes that FPC will implement. Like the System.Collection.Generics all three parts will be a symbol so you can't use them in your code. What exactly does that mean? That you can't have for example have an identifer Collection in the global scope of the interface or implementation section. Are there already some documentations, examples, fpc test units? The tests are located in $fpcdir/tests/test and are named tdotunits*.pp. Though I just notice that besides testing for correct compilation the tests never seem to check whether the correct identifier is resolved (e.g. tdotunits2 does never check whether the value is assigned to the correct variable/field). And two of the tests won't be run at all, because they don't start with a t... *sigh* You can also take a look at http://docwiki.embarcadero.com/RADStudio/XE3/en/Using_Namespaces_with_Delphi but ignore the paragraph about multi unit namespaces as this seems to be related to the old Delphi.NET only. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
On Sun, 14 Apr 2013 11:11:12 +0200 Sven Barth pascaldra...@googlemail.com wrote: On 14.04.2013 10:31, Mattias Gaertner wrote: I meant, can you give me the rules for the dotted unit name scopes that FPC will implement. Like the System.Collection.Generics all three parts will be a symbol so you can't use them in your code. What exactly does that mean? That you can't have for example have an identifer Collection in the global scope of the interface or implementation section. In the unit System.Collection.Generics or in the unit using that unit? Are there already some documentations, examples, fpc test units? The tests are located in $fpcdir/tests/test and are named tdotunits*.pp. Though I just notice that besides testing for correct compilation the tests never seem to check whether the correct identifier is resolved (e.g. tdotunits2 does never check whether the value is assigned to the correct variable/field). And two of the tests won't be run at all, because they don't start with a t... *sigh* Can you fix that? You can also take a look at http://docwiki.embarcadero.com/RADStudio/XE3/en/Using_Namespaces_with_Delphi but ignore the paragraph about multi unit namespaces as this seems to be related to the old Delphi.NET only. Does that mean FPC will support exactly that or only a subset or will it have some additions? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
On 14.04.2013 11:40, Mattias Gaertner wrote: On Sun, 14 Apr 2013 11:11:12 +0200 Sven Barth pascaldra...@googlemail.com wrote: On 14.04.2013 10:31, Mattias Gaertner wrote: I meant, can you give me the rules for the dotted unit name scopes that FPC will implement. Like the System.Collection.Generics all three parts will be a symbol so you can't use them in your code. What exactly does that mean? That you can't have for example have an identifer Collection in the global scope of the interface or implementation section. In the unit System.Collection.Generics or in the unit using that unit? I *think* in both. This feature was implemented by Paul, so your safest bet would be to ask him. :) Are there already some documentations, examples, fpc test units? The tests are located in $fpcdir/tests/test and are named tdotunits*.pp. Though I just notice that besides testing for correct compilation the tests never seem to check whether the correct identifier is resolved (e.g. tdotunits2 does never check whether the value is assigned to the correct variable/field). And two of the tests won't be run at all, because they don't start with a t... *sigh* Can you fix that? Should be possible. I'll add this to my todo list. You can also take a look at http://docwiki.embarcadero.com/RADStudio/XE3/en/Using_Namespaces_with_Delphi but ignore the paragraph about multi unit namespaces as this seems to be related to the old Delphi.NET only. Does that mean FPC will support exactly that or only a subset or will it have some additions? I hope Paul implemented all that already when he worked on dotted unit names. :) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
On Sun, 14 Apr 2013 11:43:50 +0200 Sven Barth pascaldra...@googlemail.com wrote: [...] That you can't have for example have an identifer Collection in the global scope of the interface or implementation section. In the unit System.Collection.Generics or in the unit using that unit? I *think* in both. This feature was implemented by Paul, so your safest bet would be to ask him. :) If that is true, then I guess it should be easy to implement in the codetools too. fpdoc is tricky because it has no uses sections. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
14.04.13, 18:08, Mattias Gaertner пишет: I *think* in both. This feature was implemented by Paul, so your safest bet would be to ask him. :) If that is true, then I guess it should be easy to implement in the codetools too. You mean easy implement by me? If so then I don't think it will be easy because codetools code differs from compiler code much :) If you find any difference with Delphi handling please let me know. During the feature implementation I checked it behavior with Delphi. As Sven already mentioned FPC will probably start to intensively use dotted unit names for RTL rather soon. Best regards, Paul Ishenin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus doesn't rebuild LCL if I change some include file
On 4/13/13, Jesus Reyes jesus...@yahoo.com.mx wrote: Is the include file part of the LCL package?, it seems the IDE monitors files that are included in the package, if it's not included, it's not monitored. Does this mean that I have to manually add the 3 new includefiles (for LazFileUtils.pas) in the LCL package, or will this happe automagically if I rebuild the IDE? If I have to add them manually, how do I do that? Bart -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus doesn't rebuild LCL if I change some include file
On Sun, 14 Apr 2013 13:20:16 +0200 Bart bartjun...@gmail.com wrote: On 4/13/13, Jesus Reyes jesus...@yahoo.com.mx wrote: Is the include file part of the LCL package?, it seems the IDE monitors files that are included in the package, if it's not included, it's not monitored. Does this mean that I have to manually add the 3 new includefiles (for LazFileUtils.pas) in the LCL package, or will this happe automagically if I rebuild the IDE? If I have to add them manually, how do I do that? You have to add them manually. Open the package, click on Add / Add Files Click on the button Add Files, select the 3 new files. Click on the button Add files to package. It's on my todo list to add a quick dialog that shows probably missing files. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Linux GUI Application define CONSOLE
Hi Leledumbo, Thanks for the explanation... I agree with this point of view... I have some code shared between 2 applications, running on Text mode and GUI... And I used CONSOLE directive to distinguish some specific code for GUI application... I can fix my code, using another compiler directive on Build modes... I was considering CONSOLE directive was equal on Linux and Windows... []s Daniel Conheça o Projeto ACBr - Automaçao Comercial Brasil DJSystem a Loja Patrocinadora do ACBr De: leledumbo leledumbo_c...@yahoo.co.id Para: lazarus@lists.lazarus.freepascal.org Enviadas: Sábado, 13 de Abril de 2013 14:35 Assunto: Re: [Lazarus] Linux GUI Application define CONSOLE I´m confusing... I always find out that the CONSOLE directive exists only for applications that does not require a GUI or in other words, applications that does not require a X server Linux applications are console, Linux doesn't have integrated GUI as a part of the system like Windows (which is why replacing X server with something else is quite easily possible). Everything (including X server) runs on top of it. It's just a matter of showing the console or not. Launching Lazarus from terminal will show output log during its execution without the need to redirect to file via --debug-log option, which is mandatory on Windows. How can I distinguish applications in Text mode (CONSOLE) from Graphics Applications (GUI) ? I don't think it's possible on Linux. Do you have any need for that? -- View this message in context: http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-Linux-GUI-Application-define-CONSOLE-tp4030537p4030548.html Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Linux GUI Application define CONSOLE
[]s Daniel Conheça o Projeto ACBr - Automaçao Comercial Brasil DJSystem a Loja Patrocinadora do ACBr De: Sven Barth pascaldra...@googlemail.com Para: lazarus@lists.lazarus.freepascal.org Enviadas: Sábado, 13 de Abril de 2013 18:49 Assunto: Re: [Lazarus] Linux GUI Application define CONSOLE On 13.04.2013 18:48, Daniel Simoes de Ameida wrote: I´m confusing... I always find out that the CONSOLE directive exists only for applications that does not require a GUI or in other words, applications that does not require a X server How can I distinguish applications in Text mode (CONSOLE) from Graphics Applications (GUI) ? You can't as leledumbo wrote already. The compiler will even warn if you use $apptype ... in the main program file on Unix systems, because it is simply not supported there. As a sidenote: checking for ifdef console or ifdef gui is problematic, because you will only be aware of a change if your units are completely recompiled. If you change the setting (e.g. by not using the IDE dialogs, but by manually adding apptype console to your program file) the compiler will only recompile the main program unit and your units won't detect a change. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Linux GUI Application define CONSOLE
If your design is modular enough, you can use frontend-backend architecture.
Only the frontend should differ. This could be achieved by having 2 .lpi
referencing the same backend unit, with each own frontend (user interface).
Another way would be to use build mode, differing in -Fu paths. One will
refer to the console unit, while the other to the gui. This way requires you
to have both units having the same interface. To ease maintenance, you could
instead make one unit, but the implementation part is just an {$include}
directive. This time, -Fi (instead of -Fu) will decide the path where the
include file should be searched. So the layout is like:
Solution 1 (-Fu):
-backend.pas
-frontend/
--console/
---frontend.pas
--gui/
---frontend.pas
Solution 2 (-Fi):
-backend.pas
-frontend.pas
-include/
--console/
---frontend.inc
--gui/
---frontend.inc
--
View this message in context:
http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-Linux-GUI-Application-define-CONSOLE-tp4030537p4030599.html
Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Linux GUI Application define CONSOLE
As a side note, in order to figure out if your program is running under X11
in Linux you can simply check for the DISPLAY environment variable:
program test;
uses
SysUtils;
begin
if GetEnvironmentVariable('DISPLAY') '' then
Writeln('Hello X11')
else
Writeln('Hello Console');
end.
Obviously the program will detect X11 even if it is running under a
terminal emulator like xterm, konsole, gnome-terminal, etc.
This way you can detect if the user tries to run the program from a pure
console (like a virtual terminal from Ctrl+Alt+F1 to F6 in most Linux
machines or from a remote connection via SSH) or from under X11 and use the
appropriate user interface at launch time.
On Sun, Apr 14, 2013 at 3:54 PM, leledumbo leledumbo_c...@yahoo.co.idwrote:
If your design is modular enough, you can use frontend-backend
architecture.
Only the frontend should differ. This could be achieved by having 2 .lpi
referencing the same backend unit, with each own frontend (user interface).
Another way would be to use build mode, differing in -Fu paths. One will
refer to the console unit, while the other to the gui. This way requires
you
to have both units having the same interface. To ease maintenance, you
could
instead make one unit, but the implementation part is just an {$include}
directive. This time, -Fi (instead of -Fu) will decide the path where the
include file should be searched. So the layout is like:
Solution 1 (-Fu):
-backend.pas
-frontend/
--console/
---frontend.pas
--gui/
---frontend.pas
Solution 2 (-Fi):
-backend.pas
-frontend.pas
-include/
--console/
---frontend.inc
--gui/
---frontend.inc
--
View this message in context:
http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-Linux-GUI-Application-define-CONSOLE-tp4030537p4030599.html
Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] TDBF: Initial Visual FoxPro support
Hi FPC Lazarus lists, I've been working on the tdbf code. It had rudimentary support for both Visual Foxpro and older Foxpro file formats, but mixed them up a bit. I split out the distinction so you can specify either foxpro tablelevel (25) or Visual Foxpro (30). Just like the original code and the way Visual Foxpro works though, Foxpro tables can be modified by the application programmer to include VFP only features; in this case the table is automatically upgraded to VFP level (30). Initial support for V (varchar), Q (varbinary), 0 (bytes) fields has been added, as well as support for nullable fields. Thanks to Ludo Brands for help with what bits and bytes to shift ;) There are likely still rough edges - e.g. codepage translation for V fields is probably missing; I'll continue to run and expand the dbtestfraemwork test suite to catch and improve those. Apart from the (V)FP improvements I committed today, I've recently fixed done some other work - please see the svn commit log for details. Next on the list is getting dbaseIII memo support correct for the ultimate back to the '80s feeling ;) Also, Visual Foxpro tables now show the system/hidden field _NULLFLAGS used to store null... ehrm flags; obviously this should be hidden from the programmer. Suggestions welcome, and mantis patches/bug reports as well! Thanks, Reinier -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] make installation package in linux.
Hallo . This is my first post. I'm new to lazarus, free pascal and linux. I have Imigrated from vb on windows. I have written a little program in lazarus and freepascal (Lazaruz :1.0.8, Free Pascal 2.6.2 linuxmint 14 64 bit). The program runs well in the IDE. I want now to make an install package for linux of it and realize that i do not know how. When i searched the net i got not answer. i even dont know what is the best package format for it (i.e deb, rpm ... etc.) If any of you can show me how to do it, with maybe a little example i will be very greatefull. Thx to all in advance. :) -- View this message in context: http://free-pascal-lazarus.989080.n3.nabble.com/make-installation-package-in-linux-tp4030602.html Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
Mattias Gaertner schrieb: On Sun, 14 Apr 2013 03:52:46 -0400 Anthony Walter sys...@gmail.com wrote: Normally I don't reply to a technical discussion when a question about a possible bug is posed back with (channels inner nerd) Why would you ever want to do that?... followed up attempts to chastise. But I'll give you some honest answers. The dotted unit name concept is not a simple change. It heavily effects the scope rules and resolving mechanism. +1 The dotted names have been introduced in the .NET experiment, which has been dropped later, but now they have to be for supported for compatibility with newer Delphi versions. But like Delphi provides a number of incompatible versions, FPC IMO should do the same and freeze pre-2000 (D7 compatible), Ansi (D2007?), Unicode (D2009..XE) etc. releases, and should *not* try to merge features from different Delphi versions into only one compiler and RTL. The same for Lazarus, which also should stop trying to support all Delphi versions in one LCL and IDE. It's obvious that the LCL cannot support Ansi/UTF-8 and Unicode at the same time, this has been discussed already. Also the new XE3 GUI requires a very new component library, in addition to the LCL. Other features, like the dotted unit names, can have an heavy impact on the IDE/code tools (code completion, FPDoc and its editor, Helpfile content...), and also should be supported in different Lazarus versions. The only other solution IMO would require to make many packages polymorphic, so that they can be activated depending on the version of the current project. There are many other todos, so you have to convince developers, that this feature has no simple workaround and has priority. But maybe you don't need the full dotted unit name concept. Then maybe some half implementations are enough. Beforementioned program versions must not be absolutely frozen, it may be possible to add some non-breaking support (LazBuild, Generics...) also to older FPC/Lazarus versions, as developer time, bounties etc. permit. Nothing stops FPC/Lazarus versions from being *better* than the compatible Delphi versions :-) Just my 0.02€ DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] I didn't know this was possible
Something neat just happened while using Free Pascal/Lazarus and I thought I'd share and maybe get some feedback. I am/was testing the Pascal interface to SDL 2.0 on Ubuntu. I had built a shared object library of SDL 2.0 from mercurial daily snapshots and put the binary of libSDL2.so in my /home/user/lib folder. While running a test of my audio system classes, an error was thrown (I forget to issue a Continue; in my sound mixer if a sound sample reached its end). To my surprise, I was please to see Lazarus open up the SDL 2.0 source code file (SDL_mixer.c), and pause my application while highlighting the line (in SDL_mixer.c) where the error occurred. http://www.codebot.org/sdl/sdl_error.jpg TL/DR: Lazarus can locate source code and highlight source code when an error occurs, even when the error is in a binary built in another language with a different toolkit located elsewhere in the file system. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
