On 2014-02-05 08:03, Sven Barth wrote:
> Are there any ideas for improving this situation for people that know
> that there is an identifier in the RTL, FCL, whatever, but don't know
> which unit it resides in?
Yes, simply use DocView and make sure you specified a help directory
where INF help f
Martin Frb schrieb:
On 10/02/2014 12:17, Hans-Peter Diettrich wrote:
Mattias Gaertner schrieb:
http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Change_the_output_directory_of_project_and_all_packages
Nice :-)
I don't understand the "IDE directories" in "Paths":
>>
The IDE ha
Mattias Gaertner schrieb:
Martin Frb hat am 10. Februar 2014 um 14:08 geschrieben:
[...]
I don't understand the "IDE directories" in "Paths":
The IDE has one set of search paths for every directory. That means a
package can have different search paths than the active project.
<<
Here "directo
Michael Van Canneyt schrieb:
I find makefiles with all the variables, rules and whatnot far easier to
understand than this dialog.
I only can interpret the final commandlines, generated from makefiles
after macro substitution. From there it's a puzzle to find out what
deserves an adjustment,
On 10/02/14 20:43, Mattias Gaertner wrote:
On Mon, 10 Feb 2014 19:24:18 +0100
Sven Barth wrote:
On 10.02.2014 19:20, patspiper wrote:
On 10/02/14 20:09, Mattias Gaertner wrote:
On Mon, 10 Feb 2014 19:45:44 +0200
patspiper wrote:
[...]
It allows the caller to specify the location (AFAIK it
On 10/02/14 20:48, Mattias Gaertner wrote:
On Mon, 10 Feb 2014 20:31:20 +0200
patspiper wrote:
[...]
You can't specify a ppcxxx executable directly if you cross compile.
Of course I can. I just need to specify the right ppcXXX executable.
I didn't mean it is not possible, but it is a hassle
On 10/02/14 20:31, Mattias Gaertner wrote:
On Mon, 10 Feb 2014 20:20:40 +0200
patspiper wrote:
On 10/02/14 20:09, Mattias Gaertner wrote:
On Mon, 10 Feb 2014 19:45:44 +0200
patspiper wrote:
[...]
And how can I select the right sub tools like fpcres? I still need to
specify the PATH, don't
On Mon, 10 Feb 2014 20:31:20 +0200
patspiper wrote:
>[...]
> >> You can't specify a ppcxxx executable directly if you cross compile.
> >
> > Of course I can. I just need to specify the right ppcXXX executable.
>
> I didn't mean it is not possible, but it is a hassle. You'll have to
> select at
On Mon, 10 Feb 2014 19:24:18 +0100
Sven Barth wrote:
> On 10.02.2014 19:20, patspiper wrote:
> > On 10/02/14 20:09, Mattias Gaertner wrote:
> >> On Mon, 10 Feb 2014 19:45:44 +0200
> >> patspiper wrote:
> >>
> >>> [...]
> >>> It allows the caller to specify the location (AFAIK it can be a relativ
On Mon, 10 Feb 2014 20:20:40 +0200
patspiper wrote:
> On 10/02/14 20:09, Mattias Gaertner wrote:
> > On Mon, 10 Feb 2014 19:45:44 +0200
> > patspiper wrote:
> >
> >> [...]
> > And how can I select the right sub tools like fpcres? I still need to
> > specify the PATH, don't I?
>
> When a fully q
Mattias Gaertner wrote:
On Mon, 10 Feb 2014 18:10:21 +
Mark Morgan Lloyd wrote:
[...]
The other issue is how to tell the IDE where the FPC sources are, and to
keep everything in step. I normally copy a cleaned version of the
sources into e.g. /usr/local/lib/fpc/2.6.2/fpcsrc.
/usr/local
On 10/02/14 20:24, Sven Barth wrote:
On 10.02.2014 19:20, patspiper wrote:
On 10/02/14 20:09, Mattias Gaertner wrote:
On Mon, 10 Feb 2014 19:45:44 +0200
patspiper wrote:
[...]
It allows the caller to specify the location (AFAIK it can be a
relative
path) of ppcxxx (the actual compiler). Th
On Mon, 10 Feb 2014 18:10:21 +
Mark Morgan Lloyd wrote:
>[...]
> The other issue is how to tell the IDE where the FPC sources are, and to
> keep everything in step. I normally copy a cleaned version of the
> sources into e.g. /usr/local/lib/fpc/2.6.2/fpcsrc.
/usr/local/lib/fpc/$(FPCVer)/fp
On 10.02.2014 19:20, patspiper wrote:
On 10/02/14 20:09, Mattias Gaertner wrote:
On Mon, 10 Feb 2014 19:45:44 +0200
patspiper wrote:
[...]
It allows the caller to specify the location (AFAIK it can be a relative
path) of ppcxxx (the actual compiler). That option removes the need to
rely on en
On 10/02/14 20:09, Mattias Gaertner wrote:
On Mon, 10 Feb 2014 19:45:44 +0200
patspiper wrote:
[...]
It allows the caller to specify the location (AFAIK it can be a relative
path) of ppcxxx (the actual compiler). That option removes the need to
rely on env variables to specify the fpc and ppcx
On Mon, 10 Feb 2014 19:50:14 +0200
patspiper wrote:
>[...]
> > fpc is in /usr/local/bin/fpc
> > various compilers are in /usr/local/lib/fpc/$version/ppcXXX
> >
> > or (depending on how it was installed):
> > /usr/bin/fpc
> > and
> > /usr/lib/fpc/$version/ppcXXX
> >
> > Same paths are used on Darw
Michael Van Canneyt wrote:
I do this, because lazarus does not - out of the box - support the
passing of the version to FPC as in:
fpc -V2.6.4
for instance, the above command will execute the correct binary:
ppcx64-2.6.4, as can be seen as:
home: >fpc -V2.6.4 -iV
2.6.4
home: >fpc -V2.7.1 -
On Mon, 10 Feb 2014 19:45:44 +0200
patspiper wrote:
>[...]
> It allows the caller to specify the location (AFAIK it can be a relative
> path) of ppcxxx (the actual compiler). That option removes the need to
> rely on env variables to specify the fpc and ppcxxx paths. It would be
> enough to pr
On 10/02/14 19:54, Mattias Gaertner wrote:
On Mon, 10 Feb 2014 14:44:50 +0100 (CET)
Michael Van Canneyt wrote:
[...]
I use a full path to ppcx64-x.y.z
How did you create ppcx64-x.y.z?
AFAIK none of the installers create this.
This seems to be one way to use different fpc versions with Lazar
On 10/02/14 19:26, Mattias Gaertner wrote:
On Mon, 10 Feb 2014 19:01:28 +0200
patspiper wrote:
[...]
You can not (yet) override environment variables like PATH when invoking FPC.
Once this is implemented, it can be done by "additions and overrides" too.
Although it is a welcome feature, it w
On Mon, 10 Feb 2014 14:44:50 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> I use a full path to ppcx64-x.y.z
How did you create ppcx64-x.y.z?
AFAIK none of the installers create this.
> I do this, because lazarus does not - out of the box - support the passing of
> the version to FPC as in
On 10/02/14 19:38, Michael Van Canneyt wrote:
On Mon, 10 Feb 2014, patspiper wrote:
On 10/02/14 19:12, Michael Van Canneyt wrote:
On Mon, 10 Feb 2014, patspiper wrote:
Once this is implemented, it can be done by "additions and
overrides" too.
Although it is a welcome feature, it will m
On 10.02.2014 18:26, Mattias Gaertner wrote:
I instead propose to have a field next to the compiler path in the IDE
options that accepts fpc's -Xp parameter. Xp allows one to specify the
relative folder of the actual compiler (ppcxxx) with respect to the fpc
executable. That would work well since
On Mon, 10 Feb 2014, patspiper wrote:
On 10/02/14 19:12, Michael Van Canneyt wrote:
On Mon, 10 Feb 2014, patspiper wrote:
Once this is implemented, it can be done by "additions and overrides"
too.
Although it is a welcome feature, it will make the usage really
complicated considering b
On Mon, 10 Feb 2014 19:01:28 +0200
patspiper wrote:
>[...]
> > You can not (yet) override environment variables like PATH when invoking
> > FPC.
> > Once this is implemented, it can be done by "additions and overrides" too.
>
> Although it is a welcome feature, it will make the usage really
>
On 10/02/14 19:12, Michael Van Canneyt wrote:
On Mon, 10 Feb 2014, patspiper wrote:
Once this is implemented, it can be done by "additions and
overrides" too.
Although it is a welcome feature, it will make the usage really
complicated considering build modes might cater for debug/release,
On Mon, 10 Feb 2014, patspiper wrote:
Once this is implemented, it can be done by "additions and overrides" too.
Although it is a welcome feature, it will make the usage really complicated
considering build modes might cater for debug/release, FPC version,
win/linux, etc...
I instead pro
On 10/02/14 18:21, Mattias Gaertner wrote:
- Use a script (with an fpc version variable) that includes in the
environment PATH the bin folder (where fpc is) and the compiler folder
(where
ppcx64 is) to launch the Lazarus IDE.
I don't see why you would need this.
Normally you can simply switch
On Mon, 10 Feb 2014, Mattias Gaertner wrote:
Michael Van Canneyt hat am 10. Februar 2014 um 16:57
geschrieben:
On Mon, 10 Feb 2014, Mattias Gaertner wrote:
If someone uses such a package, he can choose 'no override'. That's what I
meant
with 'keep it optional'.
Such packages (close
On 10/02/14 18:11, Mattias Gaertner wrote:
patspiper hat am 10. Februar 2014 um 16:18 geschrieben:
On 10/02/14 15:31, Mattias Gaertner wrote:
patspiper hat am 10. Februar 2014 um 14:15
geschrieben:
[...]
However, is it possible to have a category (like #project) for packages
bundled with L
> Michael Van Canneyt hat am 10. Februar 2014 um 16:57
> geschrieben:
>
>
>
>
> On Mon, 10 Feb 2014, Mattias Gaertner wrote:
>
> > If someone uses such a package, he can choose 'no override'. That's what I
> > meant
> > with 'keep it optional'.
>
> Such packages (closed source) etc. obviou
> Michael Van Canneyt hat am 10. Februar 2014 um 16:19
> geschrieben:
> [...]
> On Mon, 10 Feb 2014, patspiper wrote:
>
> > - Install different fpc versions in folders differing only by the fpc
> > version
>
> To my knowledge, this is done by default, both on Unix and on Windows.
Yes.
> > -
Am 10.02.2014 16:57, schrieb Michael Van Canneyt:
On Mon, 10 Feb 2014, Mattias Gaertner wrote:
If someone uses such a package, he can choose 'no override'. That's
what I meant
with 'keep it optional'.
Such packages (closed source) etc. obviously cannot be used with
various compiler versio
On Mon, 10 Feb 2014, Mattias Gaertner wrote:
If someone uses such a package, he can choose 'no override'. That's what I meant
with 'keep it optional'.
Such packages (closed source) etc. obviously cannot be used with various compiler
versions anyway.
But hey, never mind, my mail was not m
On 10/02/14 17:19, Michael Van Canneyt wrote:
On Mon, 10 Feb 2014, patspiper wrote:
My solution to this is:
- Install different fpc versions in folders differing only by the fpc
version
To my knowledge, this is done by default, both on Unix and on Windows.
True. I just felt I should em
On Fri, Feb 7, 2014 at 1:45 PM, Hans-Peter Diettrich
wrote:
> Flávio Etrusco schrieb:
>
>> -Flávio
>> PS. I'm Brazilian.
>
>
> Oh, I always thought you were an old Italian guy ;-)
>
> DoDi
No, that's my cousin, Flavivs Etrvscvs :-p
--
___
Lazarus maili
> Michael Van Canneyt hat am 10. Februar 2014 um 14:38
> geschrieben:
>
>
>
>
> On Mon, 10 Feb 2014, Mattias Gaertner wrote:
>
> > On Mon, 10 Feb 2014 11:57:08 +0100 (CET)
> > Michael Van Canneyt wrote:
> >
> >> [...]
> >> I never (actively) use IDE macros. Probably they get used in the
>
On 10/02/14 15:31, Mattias Gaertner wrote:
patspiper hat am 10. Februar 2014 um 14:15 geschrieben:
[...]
However, is it possible to have a category (like #project) for packages
bundled with Lazarus (LCL, lazreport, lazdaemon, etc...)?
Why do you need that?
By default, all bundled lazarus pa
On Mon, 10 Feb 2014, patspiper wrote:
My solution to this is:
- Install different fpc versions in folders differing only by the fpc version
To my knowledge, this is done by default, both on Unix and on Windows.
- Use a script (with an fpc version variable) that includes in the
environmen
On 10/02/14 15:44, Michael Van Canneyt wrote:
On Mon, 10 Feb 2014, patspiper wrote:
On 10/02/14 11:33, Michael Van Canneyt wrote:
Hello,
A single Lazarus installation
* Can work with different CPUs. * It can work with different OS-es.
* It can work with different widgetsets.
It caters for
On 10/02/2014 13:50, Mattias Gaertner wrote:
Martin Frb hat am 10. Februar 2014 um 14:08 geschrieben:
[...]
I don't understand the "IDE directories" in "Paths":
The IDE has one set of search paths for every directory. That means a
package can have different search paths than the active projec
Mark Morgan Lloyd schrieb:
Michael Van Canneyt wrote:
Ah, in this completely un-understandable dialog. I am avoiding it like
the plague :(
A GUI is meant to make things simpler, not complicate them, this
dialog is IMHO a prime example of a violation of that principle.
(somewhat like the MS
Michael Schnell schrieb:
On 02/07/2014 05:31 PM, Hans-Peter Diettrich wrote:
Window managers do not care about widgets,,,
So maybe I am confused about the term "Window Manager" (I think I did
not introduce it here)
MS Windows does not distinguish between the window manager and
widgetset,
2014-02-09 22:39 GMT-02:00 Allan E. Registos <
allan.regis...@smpc.steniel.com.ph>:
[...]
>
> The FOSS project Docker (docker.io) has a very good tutorial in my
> opinion. I am now at tutorial level 2, maybe your documentation team will
> be able to get good ideas from this project.
>
Very nice,
Am 10.02.2014 14:48, schrieb Sven Barth:
Am 10.02.2014 14:44, schrieb Michael Van Canneyt:
Maybe the lazarus devels are not aware of this -V option. It's not
widely used or propagated, after all.
The options provided by FPC are also shown in the help output since
2.7.1 (help output is always do
> Martin Frb hat am 10. Februar 2014 um 14:08 geschrieben:
> [...]
> > I don't understand the "IDE directories" in "Paths":
> > >>
> > The IDE has one set of search paths for every directory. That means a
> > package can have different search paths than the active project.
> > <<
> > Here "direc
On Mon, 10 Feb 2014, Sven Barth wrote:
Am 10.02.2014 14:44, schrieb Michael Van Canneyt:
Maybe the lazarus devels are not aware of this -V option. It's not widely
used or propagated, after all.
The options provided by FPC are also shown in the help output since 2.7.1
(help output is always d
Am 10.02.2014 14:44, schrieb Michael Van Canneyt:
Maybe the lazarus devels are not aware of this -V option. It's not
widely used or propagated, after all.
The options provided by FPC are also shown in the help output since
2.7.1 (help output is always done by ppcXXX).
Regards,
Sven
--
___
Am 10.02.2014 14:38, schrieb Michael Van Canneyt:
1. Build modes are IMHO indeed a misguided concept.
Would you please elaborate on that? I like it very much that I can
switch between Win32/Debug, WinCE/Debug and WinCE/Release configuration
options with just two mouse clicks in the project at m
On Mon, 10 Feb 2014, patspiper wrote:
On 10/02/14 11:33, Michael Van Canneyt wrote:
Hello,
A single Lazarus installation
* Can work with different CPUs. * It can work with different OS-es.
* It can work with different widgetsets.
It caters for this by adapting the compiler unit search/outp
On Mon, 10 Feb 2014, Mattias Gaertner wrote:
On Mon, 10 Feb 2014 11:57:08 +0100 (CET)
Michael Van Canneyt wrote:
[...]
I never (actively) use IDE macros. Probably they get used in the background.
[...]
Ah, in this completely un-understandable dialog. I am avoiding it like the
plague :(
A
> patspiper hat am 10. Februar 2014 um 14:15 geschrieben:
> [...]
> However, is it possible to have a category (like #project) for packages
> bundled with Lazarus (LCL, lazreport, lazdaemon, etc...)?
Why do you need that?
Mattias
--
___
Lazarus mail
On 10/02/14 11:33, Michael Van Canneyt wrote:
Hello,
A single Lazarus installation
* Can work with different CPUs. * It can work with different OS-es.
* It can work with different widgetsets.
It caters for this by adapting the compiler unit search/output path
into $(cpu)-$(os)/$(widgetset)
-
On 10/02/14 12:15, Mattias Gaertner wrote:
The "Additions and Overrides" of Lazarus 1.1+ can do that.
I added it as an example:
http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Change_the_output_directory_of_project_and_all_packages
Additions and overrides are very powerful if on
On 10/02/2014 12:17, Hans-Peter Diettrich wrote:
Mattias Gaertner schrieb:
http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Change_the_output_directory_of_project_and_all_packages
Nice :-)
I don't understand the "IDE directories" in "Paths":
>>
The IDE has one set of search p
On Mon, 10 Feb 2014 11:57:08 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> I never (actively) use IDE macros. Probably they get used in the background.
>[...]
> Ah, in this completely un-understandable dialog. I am avoiding it like the
> plague :(
>
> A GUI is meant to make things simpler, no
Mattias Gaertner schrieb:
http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Change_the_output_directory_of_project_and_all_packages
Nice :-)
I don't understand the "IDE directories" in "Paths":
>>
The IDE has one set of search paths for every directory. That means a
package can
Yeah, Flavio. I'm Brazilian too. As you said, for large audience, is good
to it in english but it's a developer option and if he didn't make this
choice, well, bing translator on it. Maybe someone could offer tor help
translating it to english but he must accept this help.
2014-02-07 12:31 GMT-02
On 02/07/2014 05:31 PM, Hans-Peter Diettrich wrote:
Window managers do not care about widgets,,,
So maybe I am confused about the term "Window Manager" (I think I did
not introduce it here)
-Michael
--
___
Lazarus mailing list
Lazarus@lists.laza
Michael Van Canneyt wrote:
Ah, in this completely un-understandable dialog. I am avoiding it like
the plague :(
A GUI is meant to make things simpler, not complicate them, this dialog
is IMHO a prime example of a violation of that principle. (somewhat like
the MS Access visual query builder)
On Mon, 10 Feb 2014, Mattias Gaertner wrote:
On Mon, 10 Feb 2014 10:33:20 +0100 (CET)
Michael Van Canneyt wrote:
[...]
However, this can be avoided to a large extent by simply also adding the
compiler version to the unit output path:
$(fpcversion)/$(cpu)-$(os)/$(widgetset)
or
$(cpu)-$(os)/
Hi,
Στις 10/2/2014 12:15 μμ, ο/η Mattias Gaertner έγραψε:
Is there any plan to add such a feature by default, or have I missed something,
and there is actually
an easier way than 2 separate installations to achieve the same effect, i.e.
use 2 compiler versions
without requiring a restart an
On Mon, 10 Feb 2014 10:33:20 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> However, this can be avoided to a large extent by simply also adding the
> compiler version to the unit output path:
> $(fpcversion)/$(cpu)-$(os)/$(widgetset)
> or
> $(cpu)-$(os)/$(widgetset)/$(fpcversion)
> or even
> $
Hello,
A single Lazarus installation
* Can work with different CPUs.
* It can work with different OS-es.
* It can work with different widgetsets.
It caters for this by adapting the compiler unit search/output path into
$(cpu)-$(os)/$(widgetset)
- and it does so by default. This is great. (th
64 matches
Mail list logo
