[fpc-devel] Project Idea: Mini-FPC
Hello, Here is an idea to help new-comers to FPC understand how it works: A new project could be created which would be called: Mini-FPC. The purpose of the project is to demonstrate how FPC compiles/builds itself and how it implements basic platform/cpu support. So the very minimum goal of the Mini-FPC is to produce an executable which can run on the platform. Optional components would be: Returning a code from the executable, this would include the need for integers. Outputting text to a console, this would include the need for strings. Everything else can then be left out like: floating point numbers, sockets, lists, classes, printers, bitmaps, perhaps even debugger or debugger support, etc. So it's trimmed down as much as possible to isolate it's core components. Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Project Idea: Mini-FPC
On Fri, September 9, 2011 03:48, Skybuck Flying wrote: Hello, Here is an idea to help new-comers to FPC understand how it works: A new project could be created which would be called: Mini-FPC. The purpose of the project is to demonstrate how FPC compiles/builds itself and how it implements basic platform/cpu support. . . Everything else can then be left out like: floating point numbers, sockets, lists, classes, printers, bitmaps, perhaps even debugger or debugger support, etc. So it's trimmed down as much as possible to isolate it's core components. 3 comments: 1) Floating point support is necessary for the compiler to compile/build itself, because floating point number support needs to be available in the compiler itself (otherwise source files containing floating point numbers cannot be processed by the compiler). 2) Needs of different users vary considerably. A user interested in compiling a simple console 'hello world' program using procedural Pascal needs only unit System and nothing else, a user creating 'hello world' in a GUI window using Object Pascal has much broader needs (broader than the compiler itself). 3) Everyone is free to create a special installation package for his own needs, but I can hardly imagine something like that becoming part of the general FPC distribution. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Building without the fp IDE
Is there a correct way of telling the build process to skip the fp IDE? I'm trying to build trunk for SPARC so I can test the two recent FPC fixes plus another in Lazarus and am getting an error when building fp which I'd rather not stop to look at right now (although I'll try to report it later). For the moment I've commented out the IDE=1 line in Makefile.fpc. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building without the fp IDE
On 09/09/2011 14:34, Mark Morgan Lloyd wrote: Is there a correct way of telling the build process to skip the fp IDE? Delete the 'ide' folder? :) A 'svn revert' can always restore it later. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building without the fp IDE
On 09/09/11 13:34, Mark Morgan Lloyd wrote: Is there a correct way of telling the build process to skip the fp IDE? I'm trying to build trunk for SPARC so I can test the two recent FPC fixes plus another in Lazarus and am getting an error when building fp which I'd rather not stop to look at right now (although I'll try to report it later). For the moment I've commented out the IDE=1 line in Makefile.fpc. I don't think there is another way. Perhaps the fpc team will accept a patch like this? Index: Makefile.fpc === --- Makefile.fpc(revision 19024) +++ Makefile.fpc(working copy) @@ -152,10 +152,12 @@ ifneq ($(wildcard ide),) IDETARGETS=go32v2 win32 win64 linux freebsd os2 emx beos haiku ifneq ($(findstring $(OS_TARGET),$(IDETARGETS)),) +ifndef NOIDE IDE=1 endif endif endif +endif [rules] .NOTPARALLEL: Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building without the fp IDE
Graeme Geldenhuys wrote: On 09/09/2011 14:34, Mark Morgan Lloyd wrote: Is there a correct way of telling the build process to skip the fp IDE? Delete the 'ide' folder? :) But won't the top-level makefile rules object to that? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building without the fp IDE
2011/9/9 Mark Morgan Lloyd markmll.fpc-de...@telemetry.co.uk: Graeme Geldenhuys wrote: On 09/09/2011 14:34, Mark Morgan Lloyd wrote: Is there a correct way of telling the build process to skip the fp IDE? Delete the 'ide' folder? :) But won't the top-level makefile rules object to that? I would just try it, these lines from Makefile.fpc may support it: # Compile also IDE (check for ide and fv dir) ifneq ($(wildcard ide),) Otherwise, I would try make IDE=0 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building without the fp IDE
Vincent Snijders wrote: 2011/9/9 Mark Morgan Lloyd markmll.fpc-de...@telemetry.co.uk: Graeme Geldenhuys wrote: On 09/09/2011 14:34, Mark Morgan Lloyd wrote: Is there a correct way of telling the build process to skip the fp IDE? Delete the 'ide' folder? :) But won't the top-level makefile rules object to that? I would just try it, these lines from Makefile.fpc may support it: # Compile also IDE (check for ide and fv dir) ifneq ($(wildcard ide),) Otherwise, I would try make IDE=0 Thanks Vincent, I'll have a play once I've achieved the primary objective which is to test fixes other people have contributed recently: not to do so promptly would border on the ungrateful :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] the new resourcestring in const translation
09.09.2011 18:36, Martin пишет: fpc recently added the ability to translate const Foo: String = resourcestring; if resourcestring changes so does Foo Any way to work around this? Probably only by duplicating the literal value which is used to initialize. because in C:\lazarus_latest\components\synedit\syneditstrconst.pp there are a lot of strings initialized that way with the intend of the old behaviour = keep an untranslated copy. Also: Is that intended for typed const? Foo in above could have been changed by user in the meantime. Yes, trying to be Delphi-compatible. In Delphi, such consts are translated. Delphi translates them once during initialization, but in FPC this is impossible to do because translation typically happens later, so the only way is to hook into SetResourceStrings. Personally I don't think this is a valuable feature, but the matter of fact is all Delphi features are implemented in FPC sooner or later - so why not to do it sooner... Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Project Idea: Mini-FPC
Have you looked at target embedded ? For what specific platform are you contemplating this for ? (i.e. what specific need is driving this question ?) It implements a very minimal set of things, basically the minimum necessary to support the language core, and the minimum necessary to support a given processor and it's system unit. John From: Tomas Hajny xhaj...@hajny.biz To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Fri, September 9, 2011 3:45:54 PM Subject: Re: [fpc-devel] Project Idea: Mini-FPC On Fri, September 9, 2011 03:48, Skybuck Flying wrote: Hello, Here is an idea to help new-comers to FPC understand how it works: A new project could be created which would be called: Mini-FPC. The purpose of the project is to demonstrate how FPC compiles/builds itself and how it implements basic platform/cpu support. . . Everything else can then be left out like: floating point numbers, sockets, lists, classes, printers, bitmaps, perhaps even debugger or debugger support, etc. So it's trimmed down as much as possible to isolate it's core components. 3 comments: 1) Floating point support is necessary for the compiler to compile/build itself, because floating point number support needs to be available in the compiler itself (otherwise source files containing floating point numbers cannot be processed by the compiler). 2) Needs of different users vary considerably. A user interested in compiling a simple console 'hello world' program using procedural Pascal needs only unit System and nothing else, a user creating 'hello world' in a GUI window using Object Pascal has much broader needs (broader than the compiler itself). 3) Everyone is free to create a special installation package for his own needs, but I can hardly imagine something like that becoming part of the general FPC distribution. Tomas ___ 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] the new resourcestring in const translation
2011/9/9 Sergei Gorelkin sergei_gorel...@mail.ru: Personally I don't think this is a valuable feature, but the matter of fact is all Delphi features are implemented in FPC sooner or later - so why not to do it sooner... There was recently a fix to Lazarus where some buttons captions were stored as constants strings and were not able to be translated. Workaround was to create a function which returns a (then translated) resource string at runtime. I also use such method in my application and dislike the fact that I have to use additional code for it, so I actually find this feature useful. -- cobines ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPDoc and inherited methods
It looks like FPDoc links to an inherited item (method), when only a short description is provided for an overridden method. Is this intended behaviour? (see Controls.TDragControlObject) The short description is shown e.g. in the class declaration, but the link from there goes to the inherited method. What's required that links go to the overridden method description instead? Please note that I don't ask for an change of this behaviour, only for a confirmation whether this is reliable behaviour (by design). DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
