On 2012-10-17 01:40, Frank Church wrote:
As the solution doesn't seem to be too difficult which file or files can
we zoom in on to fix it?
Thanks for showing interest in this. I know near zero about Makefiles
and Makefile.fpc. I'm still a bit confused with FPC though. Does FPC now
use fpmake
Well, kind-of... I don't know if C# also supports this (like Java). It
probably does, because for the last few years, Delphi has just been
copying whatever is in C#. [sad]
eg: This compiles and works in Delphi XE3.
ShowMessage('Hello World!'.ToUpper);
And there are lots more string
Graeme Geldenhuys wrote:
On 2012-10-17 01:40, Frank Church wrote:
As the solution doesn't seem to be too difficult which file or files can
we zoom in on to fix it?
Thanks for showing interest in this. I know near zero about Makefiles
and Makefile.fpc. I'm still a bit confused with FPC
On 17 Oct 2012, at 10:53, Graeme Geldenhuys wrote:
The idea seems quite simple though. Do a `$compiler -iV` where $compiler
is the starting compiler use to compile the FPC source code. If that
version doesn't match a known latest stable compiler version constant,
then report an error and
Am Wednesday 17 October 2012 11:10:22 schrieb Mark Morgan Lloyd:
Graeme Geldenhuys wrote:
On 2012-10-17 01:40, Frank Church wrote:
As the solution doesn't seem to be too difficult which file or files can
we zoom in on to fix it?
Thanks for showing interest in this. I know near zero
Hi,
I'm using FPC 2.6.0 and have a fpmake.pas program for fpGUI. To be
honest I don't really use it, but to keep it up to date. Anyway, I
noticed that if I do a 'fpmake build', that fpmake compiles many of my
units multiple times. Anywhere from 2-4 times. I double checked my
fpmake.pas unit, and
17.10.12, 17:00, Graeme Geldenhuys пишет:
Well, kind-of... I don't know if C# also supports this (like Java). It
probably does, because for the last few years, Delphi has just been
copying whatever is in C#. [sad]
...
Interesting.
This was already discussed here or fpc-devel list.
Best
On 2012-10-17 10:10, Mark Morgan Lloyd wrote:
Some slack would be desirable: stable is 2.6.0 but there are known
issues which are fixed by 2.6.1.
Nope, the FPC developers made the rules quite clear! Not even the fixes
branch is guaranteed to compile FPC Trunk. ONLY the last released FPC is
On 17 Oct 2012, at 12:08, Graeme Geldenhuys wrote:
I'm using FPC 2.6.0 and have a fpmake.pas program for fpGUI. To be
honest I don't really use it, but to keep it up to date. Anyway, I
noticed that if I do a 'fpmake build', that fpmake compiles many of my
units multiple times. Anywhere from
On 2012-10-17 10:15, Jonas Maebe wrote:
See http://www.mail-archive.com//msg25868.html and the rest of
the thread.
[embarrassed] Clearly my age is starting to show. :-) How do you find
this old messages in any case.
Your concern about cross-compiling could be an exception - FPC version
On 2012-10-17 11:17, Jonas Maebe wrote:
fpmake does not know about unit dependencies,
Ah OK. Thanks for the explanation. So if I ordered my units better in
the fpmake program, then that might reduce the multiple compiling too.
Graeme.
___
On 2012-10-17 11:15, Paul Ishenin wrote:
This was already discussed here or fpc-devel list.
The video was about Delphi XE3, which just got release... was this
Delphi functionality already existing in earlier Delphi versions too?
[sorry, I don't keep up with every Delphi feature any more]
Am 17.10.2012 12:31 schrieb Graeme Geldenhuys gra...@geldenhuys.co.uk:
On 2012-10-17 11:15, Paul Ishenin wrote:
This was already discussed here or fpc-devel list.
The video was about Delphi XE3, which just got release... was this
Delphi functionality already existing in earlier Delphi
Graeme Geldenhuys wrote:
On 2012-10-17 10:10, Mark Morgan Lloyd wrote:
Some slack would be desirable: stable is 2.6.0 but there are known
issues which are fixed by 2.6.1.
Nope, the FPC developers made the rules quite clear! Not even the fixes
branch is guaranteed to compile FPC Trunk. ONLY
On 17-10-2012 12:49, Mark Morgan Lloyd wrote:
Graeme Geldenhuys wrote:
On 2012-10-17 10:10, Mark Morgan Lloyd wrote:
Some slack would be desirable: stable is 2.6.0 but there are known
issues which are fixed by 2.6.1.
Nope, the FPC developers made the rules quite clear! Not even the fixes
Reinier Olislagers wrote:
On 17-10-2012 12:49, Mark Morgan Lloyd wrote:
Graeme Geldenhuys wrote:
On 2012-10-17 10:10, Mark Morgan Lloyd wrote:
Some slack would be desirable: stable is 2.6.0 but there are known
issues which are fixed by 2.6.1.
Nope, the FPC developers made the rules quite
On 2012-10-17 12:43, Marco van de Voort wrote:
It is kept simple on purpose. Only works on toplevel makefile (easy to
maintain), only on the toplevel all target, the required version is also
kept there (toplevel Makefile.fpc as only place).
Nice, works perfectly here under 64-bit Linux.
On 2012-10-17 11:49, Mark Morgan Lloyd wrote:
So saying if it won't compile with stable then sod off isn't helpful.
That's definitely not how I meant for it to sound [the joys of email
conversations]. Reinier summed up my thoughts. Default behaviour is to
only allow last released FPC version,
In our previous episode, Reinier Olislagers said:
work-in-progress.
So saying if it won't compile with stable then sod off isn't helpful.
Mark, I understand what you mean.
Regardless of the way Graeme put his point, I think having:
- a rough check on latest stable compiler
- a way
On 17 Oct 2012, at 14:54, Jonas Maebe wrote:
I think it's annoying that you then have to type
OVERRIDEVERSIONCHECK=1 whenever you build a cross-compiler. Even
more: it will suggest that building a cross-compiler should also be
done starting with the latest release, while in fact it they
On 2012-10-17 13:54, Jonas Maebe wrote:
...whenever you build a cross-compiler. Even more: it will suggest that
building a cross-compiler should also be done starting with the latest...
Simply update the error message to say that the version check rules
might not apply to newly implemented
In our previous episode, Jonas Maebe said:
It is kept simple on purpose. Only works on toplevel makefile (easy to
maintain), only on the toplevel all target, the required version
is also
kept there (toplevel Makefile.fpc as only place).
I think it's annoying that you then have to type
On Wed, 17 Oct 2012, Graeme Geldenhuys wrote:
On 2012-10-17 11:17, Jonas Maebe wrote:
fpmake does not know about unit dependencies,
Ah OK. Thanks for the explanation. So if I ordered my units better in
the fpmake program, then that might reduce the multiple compiling too.
If you
On 2012-10-17 14:18, michael.vancann...@wisa.be wrote:
If you specify the dependencies right, it should figure out the order by
itself.
I tried but it seems impossible, especially with uses clause pulling in
other dependencies.
I then tried fpmake from FPC 2.7.1... WOW, that made a huge
In our previous episode, Jonas Maebe said:
OVERRIDEVERSIONCHECK=1 whenever you build a cross-compiler. Even
more: it will suggest that building a cross-compiler should also be
done starting with the latest release, while in fact it they should
be built using a native compiler built
2012/10/17 Marco van de Voort mar...@stack.nl:
D:\repo\fpcmake all
makefile:2717: *** The only supported starting compiler version is 2.6.0.
You are trying to build with 2.7.1. If you are absolutely sure that the
current
compiler is built from the exact same version/revision, you can try to
On 2012-10-17 15:57, Vincent Snijders wrote:
Alternatively, it could just be a warning. Then if it fails later, the
complete output will show the reason.
I disagree. To prevent any strange side-effects (undefined behaviour),
the version check should happen as early as possible - before any
In our previous episode, Vincent Snijders said:
I thought about the 2.6.0-2.6.2 transition, but it is easy to temporarily
wrap another version check around it for a few weeks. More work, but not a
problem. (just needs documentation in rel_eng)
Alternatively, it could just be a warning.
C# is a full OO language, so I guess yes it's supported. Anyway, Delphi
doesn't seem to move toward Java, but Embarcadero is missing Anders' touch.
And this is the way they get it for free :p
--
View this message in context:
It actually uses record helpers, but the end result looks very much like
Java primitive types where you have type.ToString, type.Equals,
type.Split etc...
Not with the intent to be contrary, but for the sake of clarity in
discussion, String in Java is not a primitive type; it is a full-fledged
30 matches
Mail list logo
