Re: [fpc-devel] [patch] pscanner: differentiate between EOL & Tab characters from general Whitespace
On Sat, 2010-08-28 at 22:51 +0300, Žilvinas Ledas wrote: > Tried sample project today. Some a comment and a question: > 1) I have a strange error when the same file is modified twice (and > afterwards restored twice). One is: I'm looking at this issue atm. As soon as I have a definite solution I will commit. > 2) Where should I write comments/bug reports for fpprofiler? Please put up a bug report in mantis and assign it to me. I have updated SVN with all patches Graeme has sent me, so we should use this from now on. I have also create a separate wiki page: http://wiki.freepascal.org/fpprofiler. Feel free to add screen shots and more information. Regards, Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] pscanner: differentiate between EOL & Tab characters from general Whitespace
On Mon, 2010-09-13 at 23:31 +0200, Darius Blaszyk wrote: > On Sat, 2010-08-28 at 22:51 +0300, Žilvinas Ledas wrote: > > Tried sample project today. Some a comment and a question: > > 1) I have a strange error when the same file is modified twice (and > > afterwards restored twice). One is: > I'm looking at this issue atm. As soon as I have a definite solution I will > commit. > fixed in rev2491 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fcl-passrc pscanner patch
I've posted a patch for pscanner. Could someone please review and comment or apply? http://bugs.freepascal.org/view.php?id=17465 TIA, Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Less comprehensive progress output for fpmake
I have created a patch for fpmake that hides some of the raw compiler output. The new output looks more like scons and is actually more clear imho. You can however still get full output by passing the -v option to fpmake. http://bugs.freepascal.org/view.php?id=18051 Output with patch applied will be: >./fpmake Compiling test.pp Linking test [ 50%] Built target target1 Compiling test.pp Linking test [100%] Built target target2 Done instead of: >./fpmake Free Pascal Compiler version 2.4.0-2 [2010/03/06] for i386 Copyright (c) 1993-2009 by Florian Klaempfl Target OS: Linux for i386 Compiling test.pp Linking test /usr/bin/ld: warning: link.res contains output sections; did you forget -T? 9 lines compiled, 0.2 sec Free Pascal Compiler version 2.4.0-2 [2010/03/06] for i386 Copyright (c) 1993-2009 by Florian Klaempfl Target OS: Linux for i386 Compiling test.pp Linking test /usr/bin/ld: warning: link.res contains output sections; did you forget -T? 9 lines compiled, 0.2 sec Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Added new target to fpmake
> - Selection of output format ? > - Add to zip ? I created a new patch that implements these options. Can someone please review the patch and comment on it. Are there any other frequently used settings or conditions regarding fpdoc that should be taken in the patch? I'm happy to apply them. http://bugs.freepascal.org/view.php?id=18050 Regards, Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Added new target to fpmake
On Thu, 2010-11-25 at 16:01 +0100, dhkblas...@zeelandnet.nl wrote: > > Hi, > > Today I was playing with FPDoc and I decided to add creating the > documents as a target to fpmake which seems logical to me. I only did > a very basic implementation to show tghe principle so someone (Joost / > Michael??) can shoot at it first before I burn too much time on it. > > The bugreport is here: > http://bugs.freepascal.org/view.php?id=18050 > I've been thinking about the folder structure for fpdoc xml files. Analog to bin and example files I would like to have the xml files in the default location called fpdoc. The output will be sent to the folder called docs. From where they can be installed. Of course the locations should be overidable. Regarding Marco's comment on Mantis however I'm not sure it will be possible to link xml and sourcefiles automatically, therefore I'm not sure it could work with a default fpdoc folder. Some comments would be appreciated. Regards, Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Added new target to fpmake
> > I've been thinking about the folder structure for fpdoc xml files. > > Analog to bin and example files I would like to have the xml files in > > the default location called fpdoc. The output will be sent to the folder > > called docs. From where they can be installed. Of course the locations > > should be overidable. > > That concept seems OK to me. > Maybe --descr-folder and --doc-folder options need to be made then. Indeed. > > Regarding Marco's comment on Mantis however I'm not sure it will be > > possible to link xml and sourcefiles automatically, therefore I'm not > > sure it could work with a default fpdoc folder. Some comments would be > > appreciated. > > ? Not sure I understand wat you mean here. Marco's remark is about order of > the units. > What does that have to do with linking XML and source automatically ? If we link xml and source files automatically there is no way guaranteeing the order. That was my concern. The current implementation forces the order because it follows the order in which doc files were added in fpmake.pp. But if we adhere to this method, then there is no "special" need for a fpdoc folder. Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Added new target to fpmake
> > I've been thinking about the folder structure for fpdoc xml files. > > Analog to bin and example files I would like to have the xml files in > > the default location called fpdoc. The output will be sent to the folder > > called docs. From where they can be installed. Of course the locations > > should be overidable. > > That concept seems OK to me. > Maybe --descr-folder and --doc-folder options need to be made then. > > > Regarding Marco's comment on Mantis however I'm not sure it will be > > possible to link xml and sourcefiles automatically, therefore I'm not > > sure it could work with a default fpdoc folder. Some comments would be > > appreciated. > > ? Not sure I understand wat you mean here. Marco's remark is about order of > the units. > What does that have to do with linking XML and source automatically ? --doc-folder has been implemented. --descr-folder not yet, as we need to reach consensus on how to handle order dependency of fpdoc Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Added new target to fpmake
> Well, fpmake contains the dependencies of the units.
> Therefor you should be able to place the units in the correct order.
> So my idea would be to enforce the order by looking at the dependencies.
>
> All that is needed is to list the units that should be documented;
> The engine can then look in the list of dependencies, and if there
> are dependencies found, they can be added first.
I suppose it should look like this then:
T := P.Targets.AddFPDoc('input.pas', 'descr.xml');
T.Dependencies.Add('myunit1.pas');
T.Dependencies.Add('myunit2.pas');
Will generate the following command;
fpdoc --input=myunit1.pas --input=myunit2.pas --input=input.pas
--descr=descr.xml
Did I understand it correctly?
Regards, Darius
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Added new target to fpmake
On Sat, 2010-11-27 at 22:17 +0100, Sven Barth wrote:
> On 27.11.2010 22:10, Darius Blaszyk wrote:
> >> Well, fpmake contains the dependencies of the units.
> >> Therefor you should be able to place the units in the correct order.
> >> So my idea would be to enforce the order by looking at the dependencies.
> >>
> >> All that is needed is to list the units that should be documented;
> >> The engine can then look in the list of dependencies, and if there
> >> are dependencies found, they can be added first.
> >
> > I suppose it should look like this then:
> >
> > T := P.Targets.AddFPDoc('input.pas', 'descr.xml');
> > T.Dependencies.Add('myunit1.pas');
> > T.Dependencies.Add('myunit2.pas');
> >
> > Will generate the following command;
> >
> > fpdoc --input=myunit1.pas --input=myunit2.pas --input=input.pas
> > --descr=descr.xml
> >
> > Did I understand it correctly?
>
> I believe he meant that you can get the dependencies from the already
> added units.
>
> E.g. (from rtl/fpmake.pp):
>
> T:=P.Targets.AddUnit('classes.pp');
> T.IncludePath.Add('objpas/classes');
> With T.Dependencies do
>begin
> AddUnit('sysutils');
> AddUnit('types');
> AddUnit('typinfo');
> AddUnit('unix',AllUnixOSes);
> AddUnit('windows',AllWindowsOSes);
>end;
>
> You already know from here that 'classes.pp' depends on those units, so
> you might use those already defined dependencies to automatically add
> those units to fpdoc as well (I don't know how exactly you can and need
> to do it, but that's the theory) if you want to generate the
> documentation for 'classes'.
Yup, we're talking about the same (though I should have used AddUnit as
you did). I just wanted to have confirmation (also regarding fpdoc
command-line options).
Darius
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Added new target to fpmake
> > You already know from here that 'classes.pp' depends on those units, so > > you might use those already defined dependencies to automatically add > > those units to fpdoc as well (I don't know how exactly you can and need > > to do it, but that's the theory) if you want to generate the > > documentation for 'classes'. > > Yup, we're talking about the same (though I should have used AddUnit as > you did). I just wanted to have confirmation (also regarding fpdoc > command-line options). Uploaded a new patch to Mantis implementing the above mentioned functionality. Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Less comprehensive progress output for fpmake
On Mon, 2010-11-29 at 18:04 +0100, Joost van der Sluis wrote: > On Thu, 2010-11-25 at 18:05 +0100, Darius Blaszyk wrote: > > I have created a patch for fpmake that hides some of the raw compiler > > output. The new output looks more like scons and is actually more clear > > imho. You can however still get full output by passing the -v option to > > fpmake. > > > > http://bugs.freepascal.org/view.php?id=18051 > > > > > > Output with patch applied will be: > > > > >./fpmake > >Compiling test.pp > >Linking test > > [ 50%] Built target target1 > >Compiling test.pp > >Linking test > > [100%] Built target target2 > > Done > > Nice, this was on my todo-list. Can you now make it so that when an > error occurs, the compiler-command and output are shown by default. > (Also without -v?) Joost, The major "problem" we will have to solve is localization. Now the code depends on the words "Compiling" and "linking". Is there a way to circumvent this? I could for instance only strip the header information and show that (properly indented). What do the other say? Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Less comprehensive progress output for fpmake
On Mon, 2010-11-29 at 19:31 +0100, Jonas Maebe wrote: > On 29 Nov 2010, at 18:45, Darius Blaszyk wrote: > > > The major "problem" we will have to solve is localization. Now the code > > depends on the words "Compiling" and "linking". Is there a way to > > circumvent this? > > If you pass -vq to the compiler, it will prepend the message numbers to the > output messages. Then you can filter on these numbers (they should not change > with new compiler versions). Thanks Jonas, very useful indeed. Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Less comprehensive progress output for fpmake
On Mon, 2010-11-29 at 20:00 +0100, Darius Blaszyk wrote: > On Mon, 2010-11-29 at 19:31 +0100, Jonas Maebe wrote: > > On 29 Nov 2010, at 18:45, Darius Blaszyk wrote: > > > > > The major "problem" we will have to solve is localization. Now the code > > > depends on the words "Compiling" and "linking". Is there a way to > > > circumvent this? > > > > If you pass -vq to the compiler, it will prepend the message numbers to the > > output messages. Then you can filter on these numbers (they should not > > change with new compiler versions). > > Thanks Jonas, very useful indeed. New patch is uploaded. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] New patch for fpmake
I created a new patch for fpmake. It will now compile example programs as well. http://bugs.freepascal.org/view.php?id=18151 I also have a question regarding an idea I have for resource files. I already have made a preliminary patch (not published yet) to use rstconv to compile .rst files into a "lang" folder. Extending the idea we could also update other existing translations with the newly created .po file. eg .po -> .nl.po and .de.po Is this idea worthwhile including to fpmkunit? Regards, Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Location of documentation
I did the unthinkable ;) by trying to write some documentation for an FPC package. I searched FPC without success after which I got fpcdocs from SVN, no luck either. I only found some files included in Lazarus (\docs\xml\). What is the plan for the lack of documentation on packages? Should I add patches for FCL documentation to Lazarus or should this be corrected and subsequently documentation should be added to the packages themselves. Mind you that there was a patch applied recently that enables documentation building from fpmake. Regards, Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Location of documentation
On Mon, 2010-12-06 at 20:39 +0100, Michael Van Canneyt wrote: > Contributions are more than welcome, as long as they adhere to a strict > rule: I don't publish documentation for a unit unless it is complete. Does that mean that partial documented xml files are allowed to be added to SVN, but that they will not be published as official doc on the site? In that case, I'm ok with that. If you demand that only complete xml files are allowed in SVN than I would urge you to reconsider. Perhaps a WIP SVN repo for all I care. Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Possible bugs in TFreeTypeFont
IMHO there is a bug in TFreeTypeFont.SetFlags. The check that determines if the inherited method should be called seems to be wrong. Can someone confirm? Please consider the following patch: @@ -183,7 +183,7 @@ procedure TFreeTypeFont.SetFlags (index:integer; AValue:boolean); begin - if not (index in [5,6]) then // bold,italic + if (index in [5,6]) then // bold,italic inherited SetFlags (index, AValue); end; Secondly TFreeTypeFont.GetFlags seems to have a bug in as well. My class that descends from TFreeTypeFont calls the Bold and Italic methods, but never the correct setting is returned. Because the SetXXX method stores the settings in FFlags, I would expect FFlags to be used to restore the settings and not some value of FFace. I have modified the code (as seen below), but I guess someone should reconsider this and determine if I am right at this, or some other evaluation algorithm should be implemented instead. @@ -198,14 +198,14 @@ if index = 5 then//bold begin GetFace; -result := (FFace^.style_flags and FT_STYLE_FLAG_BOLD) <> 0; +//result := (FFace^.style_flags and FT_STYLE_FLAG_BOLD) <> 0; end else if index = 6 then//italic begin GetFace; -result := (FFace^.style_flags and FT_STYLE_FLAG_ITALIC) <> 0; -end - else +//result := (FFace^.style_flags and FT_STYLE_FLAG_ITALIC) <> 0; +end; + //else result := inherited GetFlags (index); end; Regards, Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] tprocess chopping off characters
On Jan 2, 2011, at 1:19 AM, Marco van de Voort wrote: > Hi, > > I've been making a small util that loads revisions to merge from a branch > (in my cases fixes_2_4), gets the logs, and sort the revisions into sets of > a common topic (to filter out objc and other major stuff that is not mergable) > > One of the problems is that occasionally, the output of a program doesn't > seem to be fully captured by tprocess. Like 1 in ten log messages that I > fetch misses the last couple of characters. > > Does sb recognize this behaviour? Yes I do. I added command line reading through TProcess in fpmkunit and now a compiled fpmake will show "mangled" output. However this is not always. I tried debugging, but no success so far. Darius___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Possible bugs in TFreeTypeFont
Should I create a bug report for this? Regards, Darius On Dec 16, 2010, at 1:26 AM, Darius Blaszyk wrote: > IMHO there is a bug in TFreeTypeFont.SetFlags. The check that determines > if the inherited method should be called seems to be wrong. Can someone > confirm? Please consider the following patch: > > @@ -183,7 +183,7 @@ > > procedure TFreeTypeFont.SetFlags (index:integer; AValue:boolean); > begin > - if not (index in [5,6]) then // bold,italic > + if (index in [5,6]) then // bold,italic > inherited SetFlags (index, AValue); > end; > > Secondly TFreeTypeFont.GetFlags seems to have a bug in as well. My class > that descends from TFreeTypeFont calls the Bold and Italic methods, but > never the correct setting is returned. Because the SetXXX method stores > the settings in FFlags, I would expect FFlags to be used to restore the > settings and not some value of FFace. I have modified the code (as seen > below), but I guess someone should reconsider this and determine if I am > right at this, or some other evaluation algorithm should be implemented > instead. > > @@ -198,14 +198,14 @@ > if index = 5 then//bold > begin > GetFace; > -result := (FFace^.style_flags and FT_STYLE_FLAG_BOLD) <> 0; > +//result := (FFace^.style_flags and FT_STYLE_FLAG_BOLD) <> 0; > end > else if index = 6 then//italic > begin > GetFace; > -result := (FFace^.style_flags and FT_STYLE_FLAG_ITALIC) <> 0; > -end > - else > +//result := (FFace^.style_flags and FT_STYLE_FLAG_ITALIC) <> 0; > +end; > + //else > result := inherited GetFlags (index); > end; > > Regards, Darius > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [fpprofiler] bug
Resolved in revision 2521. I added your example to the test suite. Darius On Jan 12, 2011, at 7:13 AM, Alex Shishkin wrote: > http://bugs.freepascal.org/view.php?id=18471 > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] The future of fpmake
Hi, I'm using fpmake more and more in my projects (large or small) and from time to time I come across some limitations that need to be resolved. In the past I have supplied a number of small patches which were normally applied without problems, but sometimes I was sent back (mostly with good reasons) to rethink a patch. However as I noted in http://bugs.freepascal.org/view.php?id=18151this approach is sometimes like a "trial and error" strategy and I would prefer if we could create something like a roadmap for fpmake and put that up on the wiki. Because it's a FPC program it's of course always possible to add functionality yourself. The question though is, what will FPC support out of the box. A couple of things that come to mind: - generation of documentation (fpdoc and possible other??) - compilation of example files - compilation and running of the testsuite - generation of the classchart - execute fpmake from command line (see thread by mattias : "run pascal programs as script") for this we would need instantfpc to support win32 and it should be supplied as a standard fpc tool - implement the creation of installer (scripts) for all platforms - implement a binary zip option - managing debug/release builds (also cross-compiling) - cmake like system (display and store information on builds and test suites, etc) BTW: I suppose testsuite and example files could be compiled by a separate fpmake file, but it sounds not logical to create a separate package for that, or does it? Of course these are all nice to haves, but agreeing what is in and what definitely not does not hurt. All "out of scope" functionality could be added to an external fmkextunit. Regards, Darius___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On Mar 30, 2011, at 5:31 PM, michael.vancann...@wisa.be wrote: >> - managing debug/release builds (also cross-compiling) > > What is failing in the current system for this ? I was thinking to be able to do something like : >fpmake build debug This will add some debug options to the build process. Also it should be possible to create a custom build profile. >> - cmake like system (display and store information on builds and test >> suites, etc) > > fppkg should handle that part of the job, not fpmake. To make fppkg work for my own project I need to add a fppkg.cfg to my project right? Regards, Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On Mar 30, 2011, at 5:46 PM, michael.vancann...@wisa.be wrote: > > > On Wed, 30 Mar 2011, Florian Klaempfl wrote: > >> Am 30.03.2011 17:31, schrieb michael.vancann...@wisa.be: - execute fpmake from command line (see thread by mattias : "run pascal programs as script") for this we would need instantfpc to support win32 and it should be supplied as a standard fpc tool >>> >>> I doubt this is feasible for windows. As far as I know, no #! comparable >>> construct exists. >> >> It is extension dependend on windows: typing just test.pp starts lazarus >> on my windows. > > So it does here, but I doubt this is what we want ? :-) It's not. A possible workaround is to use a distinct extension for makefiles and assign this extension to instantfpc. Regards, Darius___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On Mar 30, 2011, at 9:08 PM, Michael Van Canneyt wrote: > > > On Wed, 30 Mar 2011, Darius Blaszyk wrote: > >> >> On Mar 30, 2011, at 5:31 PM, michael.vancann...@wisa.be wrote: >> >>>> - managing debug/release builds (also cross-compiling) >>> >>> What is failing in the current system for this ? >> >> I was thinking to be able to do something like : >> >>> fpmake build debug >> >> This will add some debug options to the build process. Also it should be >> possible to create a custom build profile. > > And how would you do this ? > > I don't want to complicate fpmake unnecessarily. Improve the command line paring algorithm. It should check if there is something behind the build command line option. If so then it is a named build profile. In fpmake you could check the TDefaults.Profile property to determine which options to add. > >>>> - cmake like system (display and store information on builds and test >>>> suites, etc) >>> >>> fppkg should handle that part of the job, not fpmake. >> To make fppkg work for my own project I need to add a fppkg.cfg to my >> project right? > > There is no such thing as 'fppkg for a project', so I'm not sure what you > mean here. But I am talking about using fpmake for projects other than FPC. So the cdash (not cmake as I mistakenly wrote in the mail) idea should also work for standalone projects. Darius___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On Mar 30, 2011, at 9:12 PM, Michael Van Canneyt wrote: >> - execute fpmake from command line (see thread by mattias : "run >> pascal programs as script") for this we would need instantfpc to >> support win32 and it should be supplied as a standard fpc tool > > I doubt this is feasible for windows. As far as I know, no #! comparable > construct exists. It is extension dependend on windows: typing just test.pp starts lazarus on my windows. >>> >>> So it does here, but I doubt this is what we want ? :-) >> >> It's not. A possible workaround is to use a distinct extension for makefiles >> and assign this extension to instantfpc. > > I don't think this is needed/wanted. fpmake.pp is intended to be used in > tandem with fppkg, and that looks for a fpmake.pp program, not a script. For FPC yes, but for standalone projects this is not the case as you mentioned. Apart from that I don't see an issue even for fppkg, other than the fact that the extension might be hardcoded, which could be modified. Please note that I'm for a more holistic approach for fpmake. > (not to mention all the possible complications on Windows, probably Mac OS as > well) Can you name a potential issue you see by renaming the makefile to some other extension? I thought that FPC does not mind which extension you use, as long as the syntax is correct? Regards, Darius___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On Mar 30, 2011, at 9:29 PM, Michael Van Canneyt wrote: >> - managing debug/release builds (also cross-compiling) > > What is failing in the current system for this ? I was thinking to be able to do something like : > fpmake build debug This will add some debug options to the build process. Also it should be possible to create a custom build profile. >>> >>> And how would you do this ? >>> >>> I don't want to complicate fpmake unnecessarily. >> >> Improve the command line paring algorithm. It should check if there is >> something behind the build command line option. If so then it is a named >> build profile. In fpmake you could check the TDefaults.Profile property to >> determine which options to add. > > I would prefer a named option, i.e. > > fpmake build --profile=debug from the users perspective this is not very friendly. > and I think TDefaults.Profile needs to be a) A collection. > b) Loadable from some config file, I suppose ? > --profile then just selects one item in the collection. So you mean have a fpmake.pp and next to that a fpmake.cfg? That does not make sense. The fpmake.pp in itself is a config file (well sort of). I would just prefer to keep it simple, maybe have the user register the profiles in fpmake.pp? > Other than that, I think this is OK. > >> >>> >> - cmake like system (display and store information on builds and test >> suites, etc) > > fppkg should handle that part of the job, not fpmake. To make fppkg work for my own project I need to add a fppkg.cfg to my project right? >>> >>> There is no such thing as 'fppkg for a project', so I'm not sure what you >>> mean here. >> But I am talking about using fpmake for projects other than FPC. So the >> cdash (not cmake as I mistakenly wrote in the mail) idea should also work >> for standalone projects. > > In that case, I don't understand what you mean. > > fpmake's intended use is to compile your FPC code. I can see the use of > trying to run a testsuite, build docs and a binary zip for distribution: they > are all FPC related things. > > But it is not intended as a general build system (i.e. replace make or ant or > rpm or deb). What do you mean with "general". Fpmake is a build system right? So why not use it also for other projects? Ok, perhaps the cdash functionality belongs in a different tool (although it could be in fpmake), but let's not limit fpmake only to FPC please. Let us (end users) also play with it ;) Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On Mar 30, 2011, at 9:37 PM, Michael Van Canneyt wrote: >>> I don't think this is needed/wanted. fpmake.pp is intended to be used in >>> tandem with fppkg, and that looks for a fpmake.pp program, not a script. >> For FPC yes, but for standalone projects this is not the case as you >> mentioned. Apart from that I don't see an issue even for fppkg, other than >> the fact that the extension might be hardcoded, which could be modified. >> Please note that I'm for a more holistic approach for fpmake. > > Which means ? Which means that 1) when using fpmake outside FPC we can do whatever we want (provided we do not run into a wall because of a hardcoded extension somewhere). 2) even for FPC I see no objective argument not to change the extension. >> >>> (not to mention all the possible complications on Windows, probably Mac OS >>> as well) >> Can you name a potential issue you see by renaming the makefile to some >> other extension? I thought that FPC does not mind which extension you use, >> as long as the syntax is correct? > > It does not mind. > > Well, if you don't intend to use it for FPC, you can do all you want; > you don't need our permission for that ? I was not asking permission or did I? It was you who stated that there were complications. I just asked to name one. Don't get me wrong, there might be some, but I fail to see which. Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On Mar 30, 2011, at 11:46 PM, Michael Van Canneyt wrote: >>> fpmake build debug >>> >>> I would prefer a named option, i.e. >>> >>> fpmake build --profile=debug >> from the users perspective this is not very friendly. > > It is more clear what is meant. All other options are also specified with a > --option I won't make a fuss about this as it's also a matter of taste. More important is the functionality itself. >>> and I think TDefaults.Profile needs to be a) A collection. >>> b) Loadable from some config file, I suppose ? >>> --profile then just selects one item in the collection. >> So you mean have a fpmake.pp and next to that a fpmake.cfg? > > Not next to it, on a central location on your system. > > Rationale: > I imagine that one wants to have some often-used profiles on a central > location. > These will be machine specific: > > debug > profiling > testing > > if you download a package and compile it, you'd have to edit the fpmake.pp > and add these profiles each time. If the profiles are in a ~/.fpmake > file, which is loaded on start, then you need to define the profiles only > once, and they will be available for all packages you wish to compile. One remark, with your reasoning, all packages will support each defined profile. This is not necessarily the case, also for FPC. You could even argue quite the opposite, but as long as you have comprehensive messaging it should not be a problem, although it will generate quite some "false" errors on building. >> That does not make sense. The fpmake.pp in itself is a config file (well >> sort of). I would just prefer to keep it simple, maybe have the user >> register the profiles in fpmake.pp? > > See above for the rationale. But obviously, they must be definable in code as > well. > I see the above as an add-on to manual definition only. > As long as it's possible to register profiles in a fpmake file itself, I'm fine. For a standalone project this makes more sense. Imagine you have debug, profiling and testing setup locally but the project adds "profiling" as a build profile. Then fpmake would not recognize it (and raise some sort of error message because it's an invalid profile) until you added it yourself to the local config. So having both options is best here. >> So why not use it also for other projects? Ok, perhaps the cdash >> functionality belongs in a different tool (although it could be in fpmake), >> but let's not limit fpmake only to FPC please. Let us (end users) also play >> with it ;) > > You're of course free to do as you please. But when judging your proposals, I > will always reason from the point of view of a FPC-only build tool. You're > welcome to view it broader, but this is not the intended purpose of fpmake. > > The idea is to keep it simple to build and FPC code. As long as your > proposals do not conflict with that: feel free. Till now you're doing a good > job :-) I'm all for that. Let's live peacefully together :) -D-___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
> (not to mention all the possible complications on Windows, probably Mac > OS as well) Can you name a potential issue you see by renaming the makefile to some other extension? I thought that FPC does not mind which extension you use, as long as the syntax is correct? >>> >>> It does not mind. >>> >>> Well, if you don't intend to use it for FPC, you can do all you want; >>> you don't need our permission for that ? >> >> I was not asking permission or did I? It was you who stated that there were >> complications. I just asked to name one. Don't get me wrong, there might be >> some, but I fail to see which. > > But I didn't claim to know all possible complications. I just meant to say > that are possibly catches > which we currently don't know about; so jumping on a system that relies on > the "instantfpc" trick for all platforms may be a bit premature. The thing is > barely a week old :-) You're absolutely right of course. And I didn't want to imply we should switch in 24h :) I was just exploring the possibilities here. Using instantFPC once added as a FPC tool makes usage much more user friendly! > That said: > Obviously, you can give your fpmake script/program any extension you want for > your 'outside fpc' projects, associate whatever you want with it on all > platforms you see fit. > > But since fppkg is for the express (and only) purpose of installing FPC code > packages, I see nothing wrong with requiring .pas or .pp as an extension for > the fpmake file if it is to be used with fppkg. Also there everything you say is logic, although it does not mean that there couldn't be any other ways to reach a goal. However having an extension that is "executable" on all platforms seems like a valuable addition for FPC and Lazarus does it not? If we could reach consensus on something like .pex (for Pascal EXecutable) or whatever is appropriate and does not clash with existing software, then the FPC and Lazarus installers could associate this extension to instantFPC. Of course this is only valid for win32, but having an agreed extension would make things more transparent and uniform. Regards, Darius___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
> Imagine you have debug, profiling and testing setup locally b Should be debug, release and testing ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On Mar 31, 2011, at 9:22 AM, michael.vancann...@wisa.be wrote: > > > On Thu, 31 Mar 2011, Darius Blaszyk wrote: > >> >>> Imagine you have debug, profiling and testing setup locally b >> >> Should be debug, release and testing > > Nono, I actually meant profiling as different from debug. The difference > being that debug has all optimizations off, profiling has them all on. > > So "Release" should be added to the list:-) I understand, but this was a typo in the previous mail I wrote. I just corrected it as I mentioned "profiling" two times in the example I made. (It was rather late :) Darius___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fppkg question
Hi, I've created a trivial front end for fppkg (see lazarus mailing list) but working on this I realized that they are not grouped in any way. Currently with approx. 70 packages this is not a real problem, but if the system will get used more widely it will be impossible to deduct the purpose (and possibly other info) from the package just by it's name. Therefore I would like to request a new command named "info" that retrieves the info for a package from packages.xml. I would also like to add some more info in this file for a package: - the topic that organizes the packages (FPC core / DB / buttons / charts / dialogs / etc) - keywords to make it possible to search freely - support contact (official / community) See the following movie on youtube on a plugin system that has some of these features: http://www.youtube.com/watch?v=d9yyJmh3dyU&feature=player_embedded Are / were there any plans ever in this direction? Am I free to create a couple of patches? Regards, Darius___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fppkg question
On May 10, 2011, at 9:07 AM, wrote: > On Tue, 10 May 2011 08:30:28 +0200 (CEST), Michael Van Canneyt > wrote: >> On Tue, 10 May 2011, Darius Blaszyk wrote: >> >>> Hi, >>> >>> I've created a trivial front end for fppkg (see lazarus mailing list) but >>> working on this I realized that they are not grouped in any way. Currently >>> with approx. 70 packages this is not a real problem, but if the system will >>> get used more widely it will be impossible to deduct the purpose (and >>> possibly other info) from the package just by it's name. >>> >>> Therefore I would like to request a new command named "info" that retrieves >>> the info for a package from packages.xml. I would also like to add some >>> more info in this file for a package: >>> >>> - the topic that organizes the packages (FPC core / DB / buttons / charts / >>> dialogs / etc) >>> - keywords to make it possible to search freely >>> - support contact (official / community) >>> >>> See the following movie on youtube on a plugin system that has some of >>> these features: >>> http://www.youtube.com/watch?v=d9yyJmh3dyU&feature=player_embedded >>> >>> Are / were there any plans ever in this direction? Am I free to create a >>> couple of patches? >> >> It exists. >> >> If you look at fprepos.pp : >> >> TFPPackage = Class(TStreamCollectionItem) >>Property Name : String Read FName Write SetName; >>Property Author : String Read FAuthor Write FAuthor; >>Property Version : TFPVersion Read FVersion Write SetVersion; >>Property License : String Read FLicense Write FLicense; >>Property Description : String Read FDescription Write FDescription; >>Property HomepageURL : String Read FHomepageURL Write FHomepageURL; >>Property DownloadURL : String Read FDownloadURL Write FDownloadURL; >>Property FileName : String Read GetFileName Write FFileName; >>Property Email : String Read FEmail Write FEmail; >> end >> >> The same information can be stored in the fpmake.pp file. >> >> All this info is supposed to be output in XML format from fpmake >> --manifest. fppkg picks it up and stores it in the repository. >> >> If you want to extend it to include a category and keywords, be my guest. > > Thanks, that was the class indeed I was looking for to extend. I created a patch here: http://bugs.freepascal.org/view.php?id=19348 Please review and commit if approved. Regards, Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fppkg question
On May 13, 2011, at 1:01 PM, Michael Van Canneyt wrote: > > > On Fri, 13 May 2011, Darius Blaszyk wrote: > >>>> All this info is supposed to be output in XML format from fpmake >>>> --manifest. fppkg picks it up and stores it in the repository. >>>> >>>> If you want to extend it to include a category and keywords, be my guest. >>> >>> Thanks, that was the class indeed I was looking for to extend. >> >> I created a patch here: http://bugs.freepascal.org/view.php?id=19348 >> >> Please review and commit if approved. > > Please rework the patch. I don't want the Error->ErrorFmt, Log->logFmt > changes. > The overloaded versions exist on purpose. What is the alternative then? Any suggestion? Darius___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fppkg question
On May 14, 2011, at 12:26 PM, Joost van der Sluis wrote: > On Fri, 2011-05-13 at 13:18 +0200, Michael Van Canneyt wrote: >> >> On Fri, 13 May 2011, Darius Blaszyk wrote: >> >>> >>> On May 13, 2011, at 1:01 PM, Michael Van Canneyt wrote: >>> >>>> >>>> >>>> On Fri, 13 May 2011, Darius Blaszyk wrote: >>>> >>>>>>> All this info is supposed to be output in XML format from fpmake >>>>>>> --manifest. fppkg picks it up and stores it in the repository. >>>>>>> >>>>>>> If you want to extend it to include a category and keywords, be my >>>>>>> guest. >>>>>> >>>>>> Thanks, that was the class indeed I was looking for to extend. >>>>> >>>>> I created a patch here: http://bugs.freepascal.org/view.php?id=19348 >>>>> >>>>> Please review and commit if approved. >>>> >>>> Please rework the patch. I don't want the Error->ErrorFmt, Log->logFmt >>>> changes. >>>> The overloaded versions exist on purpose. >>> What is the alternative then? Any suggestion? >> >> Never mind. I fixed it myself. Rev 17440. > > I don't like the 'laz_list' exception in pkghandler.pp. I don't want any > third-party-dependent code in fppkg. And binding on a specific name > isn't fine either. fppkg should be for general use, if you need > something special, use an add-in. > In this case it is probably also possible to come up with another > solution. (why is it for, anyway?) As far as I found, the "list" action get's cached in the ExecuteActions and if found the action is not executed, but rather the action is ignored. While perfectly suitable for fppkg which is only run once though and then exits, the GUI version stays active and can run the same actions multiple times. This makes me think that I should probably create a Laz_ExecuteAction procedure and keep the original procedure in tact. I will create a patch for it. Regards, Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Fppkg questions
While working on the lazarus GUI I could not find evidence that fppkg is capable of supporting multiple repositories. As far as I can tell the mirrors.xml is always downloaded from the freepascal server and only holds some alternatives to get the packages from. I think it would be a nice feature if users could setup their own repositories and only have to distribute a repository manifest file (or URL) that will be merged with the local mirrors.xml, subsequently the packages are automatically updated into packages.xml. Is this idea eligible for support before I start working on this? Additionally I have done some tests with SVNClasses from Vincent to add support to use sources directly from SVN as packages. So instead of zipping the sources and putting them on a FTP server somewhere you actually use a SVN path (eg tags for stable releases) for a package. This requires some additional properties to TFPMirrors (Protocol < to distinguish between downloading a zip or exporting SVN) and TFPPackage (Mirror < to be able to create the link between the package and the mirror). I could create a simple patch for this feature so we can discuss implementation details later, but I wanted to discuss this high level first. Regards, Darius___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fppkg questions
On May 22, 2011, at 6:04 PM, Michael Van Canneyt wrote: > > > On Sun, 22 May 2011, Darius Blaszyk wrote: > >> While working on the lazarus GUI I could not find evidence that fppkg is >> capable of supporting multiple repositories. As far as I can tell the >> mirrors.xml is always downloaded from the freepascal server and only holds >> some alternatives to get the packages from. >> I think it would be a nice feature if users could setup their own >> repositories and only have to distribute a repository manifest file (or URL) >> that will be merged with the local mirrors.xml, subsequently the packages >> are automatically updated into packages.xml. >> Is this idea eligible for support before I start working on this? > > Having this was the idea from day one. Strange that you could not find this ? Can you point out to me how this is supposed to work then? I modified the mirrors.xml file manually but it got overwritten by the version from the freepascal repository. How are you supposed to add additional mirrors? Also the packages, how do you distinguish which package comes from which mirror? I believe you when you say this was planned, but was it implemented? > >> Additionally I have done some tests with SVNClasses from Vincent to add >> support to use sources directly from SVN as packages. So instead of zipping >> the sources and putting them on a FTP server somewhere you actually use a >> SVN path (eg tags for stable releases) for a package. This requires some >> additional properties to TFPMirrors (Protocol < to distinguish between >> downloading a zip or exporting SVN) and TFPPackage (Mirror < to be able to >> create the link between the package and the mirror). >> I could create a simple patch for this feature so we can discuss >> implementation details later, but I wanted to discuss this high level first. > > If the SVNClasses can be put in FPC, then this is not a problem and even a > good idea. > If the support for SVN requires the use of Lazarus, then it cannot be put in > fppkg. > > Michael. > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with func/proc parameters and buttons in Laz
Hi Vojtěch, First, I would like to point you that you have to send your Lazarus questions to the Lazarus mailinglist and not to the FPC-devel please. Having that said, > 1, I have no text on BitmapButtons in Lazarus in DialogBoxes (except > Open/Save file). There are only small icons on it. I tried to change > Environment - Environment Options - Desktop to other languagues and to > change these options (Hints for components palette and Hints for main > speed buttons) but no success. At what stage do your captions disappear? Do you see any in the IDE? Did you try to create a new project and put some buttons on there? What do you see? > 2, When I write procedure or function with parameter String[31] it > doesn't work. It writes Forward declaration not solved, however it is. Please provide a minimal example. You probably have some syntax problem. Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with func/proc parameters and buttons in Laz
> > > 2, When I write procedure or function with parameter String[31] it > > > doesn't work. It writes Forward declaration not solved, however it is. > > Please provide a minimal example. You probably have some syntax problem. What you would like to do in this case is to declare a custom type: MyStringType = string[31]; And replace your code by : function Test(s: MyStringType): boolean; HTH Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is LNet planned to be included in a fpc release?
On Mon, 2008-12-08 at 14:38 +0100, Vincent Snijders wrote: > Andrew Haines schreef: > > ? > > AFAIK, it is not. I think we should consider adding it to lazarus/components > or > lazarus/components/lhelp, to support loading html files from internet with > http in > lhelp. It's strange to not be included in FPC already, as the fppkg tool depends on lnet itself. Look under utils/fppkg. Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
