On Mon, Aug 20, 2007 at 05:42:26PM +1000, David Lyon wrote:
> The model is that you download the source you need and compile it into your
> own system.
That's no problem, and already the case.
>> Define "load". Also keep in mind that Perl installs interpreter
>> sourcecode, what exactly do you imagine for FPC? compiled libs, source?
>> How do you deal with versioning?
>>
> Right. That's what perl does. We should do the same thing. Then compile it
> into a library that we can use.
I don't understand what you really want to add. The perl reference is next
to useless. Please be more descriptive.
>>> - the compilable source files get compiled at package load time
>>> and "integrated" into the system for use in the "uses" clause.
>>>
>>
>> I don't think it is wise to bother the compiler with the packaging system.
>>
> It has no feelings.... :-) no pain will be caused by say 3 seconds of
> compiling.
It has no knowledge of lazarus, all it knows are stuff like directories to
search for source.
>> Keep in mind we are not a scripting system, but a compiler. The whole idea
>> is that the end-users of a binary don't need the whole shebang.
>>
> I agree. It is a compiler. So we shouldn't be afraid to ask it to compile
> an extra file for us.
>
> The issue is more about platform independance and download size. By
> distributing packages in source code and compiling them after download, it
> means quicker downloads and less time recompiling the whole of lazararus
> just to add in a new package.
How is this different than e.g. fppkg ?
>>> - fpc/lazarus uses these library files just as it would
>>> internal functions...
>>>
>>
>> That is impossible. (or you use "internal functions" entirely the wrong
>> way).
>>
> Why impossible ?
>
> At compile time, the compiler could decide whether the function is
> "internal" ie within the lazarus library files, or "external" within the
> users library directory.
Well, the compiler knows nothing about lazarus.
> But I have noticed that we are using the GNU ld linker and I have been
> exposed to that a bit in the past. I know what that thing can do and what
> it can't.
(actually starting with 2.1.x/2.2 not on windows anymore)
> When I use GLScene in Lazarus, ld takes an enourmous amount of time to
> link. It is unbearable. ld is being asked to write in all the glscene code
> into the .exe and seems to take forever (15+ seconds).
> I would prefer to have the option to link against the runtime libraries
> dynamically. This would save so much time.
Well, I actually don't know that, but it could be yes. But that would
require "library packages" like Delphi has and is far off. Further, it is
pretty unrelated to the source packaging system.
> As far as I am aware, it is only a matter of changing the command line
> parameters when ld is being called, and ensuring that all the libraries
> that are being linked against are in the correct directories.
_IF_ you have a valid librarypackaging system (shared lib generation on
pascal level) system. But this is maybe as big as a change as e.g. adding a
ELF internal linker.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
