On Tue, 30 Jul 2002 20:26:24 +0200, [EMAIL PROTECTED] wrote:
>> >> >> Disadvantages:
>> > Regarding resource compiler - well, this
>> >one is _not_ really needed, at least not in the beginning (for this,
>> >at least). However, we'll need resource compiler later anyway as well
>> > - how would you store e.g. icons, bitmaps, etc., otherwise? OTOH,
>> >creating a resource compiler shouldn't be that hard hopefully.
>> You are looking from developers point of view. But for user esely
>> don't think about developer's tools, like linker & rescompiler. For us
>> resource compiler is required, of couse. If we'll use DLL then _each_
>> program _must_be_ use DLLs for national language support. Bad. Very
>> bad.
> OK. You could link the resourcestrings to the executable just like
>you want to do with .msg, so this isn't very different, in fact.
��. Let's try from another side. We can add resources to DLL by
rc languages.rc languages.dll
without any linker/compiler. But how to add language2, language3, etc???? Make new
DLL? If so, then new DLL required and hence we must compile and link new dll. So,
for the new language required
1) rescompiler
2) compiler
3) linker
Do you think users has such things? I think no.
> > I still think limiting ourselves to IBM tools (available
> >on OS/2 only and nowhere else) isn't a good idea. In addition, you'd
> >have to add support for this into the compiler, which would mean a
> >need for your own FPC branch (because such unportable construction
> >will probably never be included in the main branch) with all its
> >disadvantages.
> Oh, now I see why you reject such solution. But I'm only about
> SPCC/SVDE, not about RTL. If anyone want to have portable classes
> I'm not really talking about RTL, in fact - I'd expect you might
>want to have some support for creating both executables and their
>message files (even more in case you're considering linking the
>message files to executables directly). This would need changes in
>the _compiler_.
No, no. No any changes. Making and linking messages to executable made like this:
1) compile messages source:
mkmsgf source.txt sibyl.msg
2) if required, bind msg file to executable
msgbind scriptfile
scriptfile is info about msgfile(s) and exefile.
So, no any changes to compiler.
>> BTW, msg compiler can be easely written. I found some msg decompiler
>> tools (with src), so we can write an msg compiler. Also, no any
>> additions to compiler is required.
> OK, let's see. Own msg compiler would help probably (because it
>would still make cross-compilation it possible; yes, I know you don't
>like this argument ;-) ).
Also, msgcompiler can be included to LanguageManager of program, so no any additional
external unils will be required. I consider this is best solution.
BTW, I prefer to use cross-compiler tools for cross-compiler libs/programs, but not
for native. Cross-compilation limits in developing and, in most cases, cross-platform
things slowly. This is like gnu development tools: I must use stupid sh, perl, awk,
etc. instead of usual rexx, alway execute one, two, three and more tools, instead of
one.
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe sibyl
end
