2011/8/9 Joost van der Sluis :
> On Mon, 2011-08-08 at 14:57 +0200, Vincent Snijders wrote:
>
>> It seems that the conversion of fcl-base to fpmake still has a glitch:
>
> Can you test with r18155?
>
It works, thanks,
Vincent
___
fpc-devel maillist - f
On Mon, 2011-08-08 at 14:57 +0200, Vincent Snijders wrote:
> It seems that the conversion of fcl-base to fpmake still has a glitch:
Can you test with r18155?
Joost.
--
My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog
___
fpc-devel mailli
Am 09.08.2011 17:04, schrieb Jeppe Græsdal Johansen:
> On 09-08-2011 15:53, Geoffrey Barton wrote:
>>
>> On 9 Aug 2011, at 14:14, John Clymer wrote:
>>
>>> I was thinking more of a generic controller class, including a
>>> memory.def (or whatever one wants to name it) file. That would be
>>> easie
DaWorm schrieb:
For what it's worth, IAR's C compiler for Cortex-M3 uses an ICF file
to hold that information, so there is precedent for doing it that way.
It holds the following (edited slightly to remove fluff):
[...]
IMO these are all values required by the linker, not by the compiler
itsel
On 09-08-2011 15:53, Geoffrey Barton wrote:
On 9 Aug 2011, at 14:14, John Clymer wrote:
I was thinking more of a generic controller class, including a
memory.def (or whatever one wants to name it) file. That would be
easiest as it would only effect the t_embed.pas file (and cpuinfo.pas
file
For what it's worth, IAR's C compiler for Cortex-M3 uses an ICF file
to hold that information, so there is precedent for doing it that way.
It holds the following (edited slightly to remove fluff):
define symbol __ICFEDIT_intvec_start__ = 0x0800;
define symbol __ICFEDIT_region_ROM_start__ = 0
On 9 Aug 2011, at 14:14, John Clymer wrote:
> I was thinking more of a generic controller class, including a memory.def (or
> whatever one wants to name it) file. That would be easiest as it would only
> effect the t_embed.pas file (and cpuinfo.pas file to add the generic type.)
>
> Haven't l
I was thinking more of a generic controller class, including a memory.def (or
whatever one wants to name it) file. That would be easiest as it would only
effect the t_embed.pas file (and cpuinfo.pas file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be
On 08/09/2011 11:28 AM, Graeme Geldenhuys wrote:
I'm pretty sure Kylix and CLX would have worked if Borland just paid a
bit more attention to quality and better marketing.
+1
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lis
On 08/08/2011 10:00 PM, Sven Barth wrote:
It will be interesting to see whether they want to license Cooper,
RemObject's upcoming Pascal compiler for Java, as well; their plans to
support Android as well in the future could mean this.
Of course Cooper would be a way to support Android for framew
On 9 August 2011 09:49, Mark Morgan Lloyd wrote:
>
> I don't think that the VCL was the issue with Kylix. The issues were (a)
> uncertainty over the Linux community's acceptance of a non-free development
>
Add to that list:
- CLX was buggy as hell because they didn't even write the Kylix ID
In our previous episode, Mark Morgan Lloyd said:
[ Charset windows-1252 unsupported, converting... ]
> Hans-Peter Diettrich wrote:
>
> > IMO CodeGear stumbled with Delphi.NET over the same stone as with Kylix:
> > the Win32 centric VCL :-(
>
> I don't think that the VCL was the issue with Kylix.
> -Message d'origine-
> De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
> boun...@lists.freepascal.org] De la part de Geoffrey Barton
> Envoyé : mardi 9 août 2011 10:20
> À : FPC developers' list
> Objet : Re: [fpc-devel] Arm Thumb2 - Stellaris status
>
>
> On 8 Aug 2011,
On 8 Aug 2011, at 21:13, Florian Klämpfl wrote:
> Am 08.08.2011 12:49, schrieb John Clymer:
>> Kicking it around in the back of my head at work today...
>>
>> I tried doing a compile to assembly language for the stellaris - and it
>> choked giving the error from t_embed.pas. The error comes fro
Hans-Peter Diettrich wrote:
IMO CodeGear stumbled with Delphi.NET over the same stone as with Kylix:
the Win32 centric VCL :-(
I don't think that the VCL was the issue with Kylix. The issues were (a)
uncertainty over the Linux community's acceptance of a non-free
development environment and
15 matches
Mail list logo
