On Sun, 12 Feb 2017, fredvs wrote:
For example, TProcess also is very os dependent and it uses
"environnement"
parameter (that is also very os dependent).
No it is not. Every OS has an environment ?
So it is exactly what I propose:
a TLoadLibrary with some features adapted for librarie
>> For example, TProcess also is very os dependent and it uses
"environnement"
>> parameter (that is also very os dependent).
> No it is not. Every OS has an environment ?
So it is exactly what I propose:
a TLoadLibrary with some features adapted for libraries that TProcess uses
for executable
> But thinking that the compiler itself will automagically determine the
path: that's simply not realistic.
Really ?
When the compiler reads uses section and find a "in" like here :
uses myunit in '/thepath/src/myunit.pas';
He could do something like:
...
if fpcword = 'in' then begin
IncludeS
On Sun, 12 Feb 2017, fredvs wrote:
Loading libraries is handled by the OS, not by the compiler or the RTL
and every OS has its own way to deal with dependencies.
Yes but the compiler could give some command to the os too...
Of course every OS has its own way to deal with dependencies but th
> Loading libraries is handled by the OS, not by the compiler or the RTL
> and every OS has its own way to deal with dependencies.
Yes but the compiler could give some command to the os too...
Of course every OS has its own way to deal with dependencies but that is the
power of fpc, he knows ho
On 12.02.2017 19:25, fredvs wrote:
> For example, fpc can load dynamically libraries but it is not usable if that
> libraries depend on other libraries.
>
> It would be great (IMO) if fpc provide, unlike other compilers, some more
> modern ways to use things (units, libraries, etc...) with the ap
> Why is using -Fu hard?
Yes, of course it could be a solution but I would prefer something inside
the code.
By the way, IMO, and it is valable for lot of languages, the way to
define/use the path (of units or libraries or dependencies) is very archaic.
Only LD_LIBRARY_PATH for libraries and fo
In our previous episode, Mattias Gaertner said:
> > > ../someunit instead of configuring -Fu which can be obnoxious and
> > > tedious.. But that's just one use case. Another use case, AFAIR was a
> > > build system instead of gnu make.
> >
> > IMHO these are all shaky uses cases, and actually
On Sun, 12 Feb 2017 16:17:01 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:
>[...]
> > One example might be when you are writing a quick program and don't want
> > to send in a whole bunch of -Fu options and go into dialog boxes in
> > lazarus configuring it, so you just quickly write it
In our previous episode, Lars said:
> I have found some use cases for hard coded paths in the source files..
> although these use cases are rare. I think even delphi main project DPR
> file does this, if I remember correctly, but I found other uses cases
> other than that.
I think that is the main
On Sun, 12 Feb 2017 15:33:23 +0800
Tim Veldhuizen wrote:
> Indeed, I can confirm Delphi does this. I think since 2009 or XE or so,
> but AFAIK it doesn't need to. It does it only for the files that are
> explicitly added to the project, but those are also in the dproj file.
> And it would comp
On 2017-02-12 01:33, Tim Veldhuizen wrote:
Indeed, I can confirm Delphi does this. I think since 2009 or XE or
so,
I'm too lazy to check right now, but I think even delphi 5 and such used
paths in the dpr (project) file
Would be interesting to find out the real reason, but once again, I'm
t
12 matches
Mail list logo
