On Tue, 20 Jul 2010 19:57:39 +0200
Zaher Dirkey parm...@gmail.com wrote:
uses
myunit in '..\lib\myunit.pas',
it is no need to change it even in the search path.
I meant my project have folders like
/proj/bin
/proj/src
/proj/lib
i can move the dir /proj or my component package
On Wed, 21 Jul 2010 11:04:37 +0200
Zaher Dirkey parm...@gmail.com wrote:
On Wed, Jul 21, 2010 at 8:37 AM, Mattias Gaertner nc-gaert...@netcologne.de
wrote:
On Tue, 20 Jul 2010 19:57:39 +0200
Zaher Dirkey parm...@gmail.com wrote:
uses
myunit in '..\lib\myunit.pas',
2010/7/19 Mattias Gärtner nc-gaert...@netcologne.de
Even then: If you move/rename a directory with target units, you have to
adapt all 'in' of using units.
If you use search paths you only have to adapt one.
example
uses
myunit in '..\lib\myunit.pas', ...
it is no need to change it even
uses
myunit in '..\lib\myunit.pas',
it is no need to change it even in the search path.
I meant my project have folders like
/proj/bin
/proj/src
/proj/lib
i can move the dir /proj or my component package to any dir without need a
changes.
The other way we can use extrafpc.cfg, we can put
On Tue, Jul 20, 2010 at 2:50 PM, Zaher Dirkey parm...@gmail.com wrote:
2010/7/19 Mattias Gärtner nc-gaert...@netcologne.de
Even then: If you move/rename a directory with target units, you have to
adapt all 'in' of using units.
If you use search paths you only have to adapt one.
example
On Sun, Jul 11, 2010 at 11:21 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote:
On 11 Jul 2010, at 15:47, Hans-Peter Diettrich wrote:
I know that the in filespec is part of the Delphi syntax, but what is
it really good for?
AFAIK it's not allowed to rename units this way, and since
On Fri, Jul 16, 2010 at 6:20 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Thu, 15 Jul 2010 09:26:24 -0300
Marcos Douglas m...@delfire.net wrote:
On Wed, Jul 14, 2010 at 6:35 PM, Stefan Kisdaroczi ki...@hispeed.ch wrote:
I'm still using it. Or make a symlink:
ln -s rar/zip.pas
On Wed, Jul 14, 2010 at 6:35 PM, Stefan Kisdaroczi ki...@hispeed.ch wrote:
I'm still using it. Or make a symlink:
ln -s rar/zip.pas rar.pas
In combination with {$L xzy.o} and 'external name ...' you can do
wonderful things. Don't do this at home! (maybe at work :-)
Okay... this is very
On 07/14/2010 09:40 PM, Sven Barth wrote:
(Can someone comment on FreeDOS regarding this?)
If it's file system provides ;MS-DOS-style long filenames, users of
same might be sued by M$ (like TomTom).
-Michael
___
fpc-devel maillist -
On 07/14/2010 11:35 PM, Stefan Kisdaroczi wrote:
Or make a symlink:
Happily even Windows NTFS does support symlinks, even though hardly
anybody uses this. ;)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Hi!
Am 15.07.2010 09:49, schrieb Michael Schnell:
On 07/14/2010 09:40 PM, Sven Barth wrote:
(Can someone comment on FreeDOS regarding this?)
If it's file system provides ;MS-DOS-style long filenames, users of same
might be sued by M$ (like TomTom).
But why should they sue an open source
But why should they sue an open source MS-DOS clone
[snip]
Please take that discussion to the fpc-other list.
Jonas
FPC mailing lists admin
This message was sent using IMP, the Internet Messaging Program.
On 07/13/2010 06:27 PM, Jonas Maebe wrote:
b) indeed also because of the searching for filenames with different
cases.
It might sometimes indeed make sens to not be forced to use the same
name for the unit and the file containing it's source code.
So using in with just a file name, without
Michael Schnell wrote:
On 07/13/2010 06:27 PM, Jonas Maebe wrote:
b) indeed also because of the searching for filenames with different
cases.
It might sometimes indeed make sens to not be forced to use the same
name for the unit and the file containing it's source code.
So using in with
In our previous episode, Thaddy said:
Yes, but that defeats unit aliasing by renaming: like uses foo in
bar.pas instead of uses foo (implies in foo.pas). Did somebody
mention this in the discussion?
Programmers are not very imaginative in naming. It is plainly helpfull
to be able to
Marco van de Voort wrote:
In our previous episode, Thaddy said:
Ok, you write always cheerful, I was merely pointing out it is not
clean, but useful :))
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Wed, Jul 14, 2010 at 7:49 AM, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Thaddy said:
Yes, but that defeats unit aliasing by renaming: like uses foo in
bar.pas instead of uses foo (implies in foo.pas). Did somebody
mention this in the discussion?
Programmers are
Thaddy schrieb:
Programmers are not very imaginative in naming. It is plainly helpfull
to be able to rename a file if another file with a different content.
Just in the FPC compiler case many unit names are hard coded, while the
files to use reside e.g. in a specific machine directory,
On Wed, Jul 14, 2010 at 10:03 AM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Thaddy schrieb:
Programmers are not very imaginative in naming. It is plainly helpfull to
be able to rename a file if another file with a different content.
Just in the FPC compiler case many unit names
On 2010-07-14 16:26, Marcos Douglas wrote:
I am surprised as there is no conflict of names of units in the FPC /
Lazarus.
There are names very short, which could be used as variable names...
Is there, still, a platform (where FPC can be used) that restricts
filenames to being so short?
On Wed, 14 Jul 2010 12:23:00 -0300
Marcos Douglas m...@delfire.net wrote:
On Wed, Jul 14, 2010 at 11:45 AM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Wed, 14 Jul 2010 10:26:11 -0300
Marcos Douglas m...@delfire.net wrote:
[...]
I am surprised as there is no conflict of names of
On Wed, Jul 14, 2010 at 12:32 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Wed, 14 Jul 2010 12:23:00 -0300
Marcos Douglas m...@delfire.net wrote:
On Wed, Jul 14, 2010 at 11:45 AM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Wed, 14 Jul 2010 10:26:11 -0300
Marcos
On Wed, 14 Jul 2010 12:51:29 -0300
Marcos Douglas m...@delfire.net wrote:
On Wed, Jul 14, 2010 at 12:32 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Wed, 14 Jul 2010 12:23:00 -0300
Marcos Douglas m...@delfire.net wrote:
On Wed, Jul 14, 2010 at 11:45 AM, Mattias Gaertner
On Wed, Jul 14, 2010 at 12:59 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Wed, 14 Jul 2010 12:51:29 -0300
Marcos Douglas m...@delfire.net wrote:
On Wed, Jul 14, 2010 at 12:32 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Wed, 14 Jul 2010 12:23:00 -0300
Marcos
On Wed, 14 Jul 2010 13:54:10 -0300
Marcos Douglas m...@delfire.net wrote:
[...]
I would tell the devels of the framework.
And if they want to keep it, then I can not use both Dialogs units. I
had not yet the case where I needed both and can not rename both.
Then, another example:
You
On Wed, Jul 14, 2010 at 2:05 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Wed, 14 Jul 2010 13:54:10 -0300
Marcos Douglas m...@delfire.net wrote:
[...]
I would tell the devels of the framework.
And if they want to keep it, then I can not use both Dialogs units. I
had not yet
In our previous episode, Marcos Douglas said:
And if they want to keep it, then I can not use both Dialogs units. I
had not yet the case where I needed both and can not rename both.
Then, another example:
You want to work with ZIP and RAR format files. So, imagine you found,
on the net, 2
In our previous episode, Marcos Douglas said:
And now, you understood the little problem?
Of course I understand the problem, but I have not yet encountered
it in a real project.
So, if we can to put an alias to unit names, there are no more problem.
I had this problem in real
On Wed, Jul 14, 2010 at 2:21 PM, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Marcos Douglas said:
And if they want to keep it, then I can not use both Dialogs units. I
had not yet the case where I needed both and can not rename both.
Then, another example:
You want
On 14.07.2010 18:54, Marcos Douglas wrote:
On Wed, Jul 14, 2010 at 12:59 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Wed, 14 Jul 2010 12:51:29 -0300
Marcos Douglas m...@delfire.net wrote:
On Wed, Jul 14, 2010 at 12:32 PM, Mattias Gaertner
nc-gaert...@netcologne.de
Marcos Douglas schrieb:
On Wed, Jul 14, 2010 at 2:55 PM, Stefan Kisdaroczi ki...@hispeed.ch wrote:
create a rar.pas containing only the line:
{$include rar/zip.pas}
compile with:
fpc -Un rar.pas
-UnDo not check where the unit name matches the file name
Interesting...
Anyone
Hello Mattias,
Wednesday, July 14, 2010, 7:05:01 PM, you wrote:
And now, you understood the little problem?
MG Of course I understand the problem, but I have not yet encountered
MG it in a real project.
I can vaguely remember a case like this in Delphi several years ago,
but I think the
In our previous episode, Jonas Maebe said:
Even for portability purposes it often doesn't work, since usually the build
systems and files for FPC/Lazarus and Delphi differ anyway (and you noticed
the working dir difference)
The working dir difference is a Lazarus difference, not an FPC
On 07/13/2010 11:46 AM, Marco van de Voort wrote:
The whole paths in source is evil IMHO.
+1,
But id _could_ be overcome e.g. by multiple unit search passes to be
defined and do something like in 2:xxx to define unit xxx to be searched
in the 2nd unit search path (while no : means normal
Marco van de Voort schrieb:
Nobody is talking about removing ? It is more a matter of not expanding, and
not guaranteeing too much (more) wrt to it. Specially since DoDi in other
posts seemed to state that he wanted to use it to override which unit is
selected in multiple sources in path cases.
Marco van de Voort wrote on Tue, 13 Jul 2010:
In our previous episode, Jonas Maebe said:
Furthermore, at least two of the users have already posted in this
thread saying that they use this functionality (both in FPC and in
Delphi). Therefore I don't think it is a good idea to remove or change
On Mon, 12 Jul 2010, Hans-Peter Diettrich wrote:
Jonas Maebe schrieb:
That is incorrect. Relative file names do work. They are resolved
relative to the current working directory of the compiler.
So what's the current working directory?
The current directory when the compiler was started.
Op 2010-07-11 15:47, Hans-Peter Diettrich het geskryf:
I know that the in filespec is part of the Delphi syntax, but what
is it really good for?
As far as I know, it was introduced in Delphi/Kylix to notify the IDE of
what units are part of the project. Instead, Lazarus IDE does this with
.lpi
In our previous episode, Hans-Peter Diettrich said:
That's why I would restrict the usage of in, with a (relative) path,
to a program or library module, as AFAIR Delphi does, and make the
directory of that file the root for relative filenames.
AFAIK it does not. Delphi projects with
Op 2010-07-12 09:01, Marco van de Voort het geskryf:
The IN syntax was iirc mainly to fix certain Kylix naming issues, and to
assist the designer (hence its main use in .dpr).
As far as I know the in syntax was used in Delphi .dpr files, long before
Kylix arrived. It was initially used by
Jonas Maebe schrieb:
I know that the in filespec is part of the Delphi syntax, but
what is it really good for?
AFAIK it's not allowed to rename units this way, and since
(currently) only absolute filenames are implemented,
That is incorrect. Relative file names do work. They are resolved
On 07/11/2010 11:31 PM, Michael Müller wrote:
We use relative paths like '..\foo\foo.pas' or '..\..\foo\foo.pas' under
Windows and it works with FPC 2.4.0 (but it already worked with 2.2.4).
Portability nightmare .
-Michael
___
fpc-devel
On 07/12/2010 08:12 AM, Michael Van Canneyt wrote:
So for historical reasons, FPC is stuck with the 'in' clause, when in
fact it should
not exist in the first place.
It could be made useful when
- it takes precedence above the search path
- can bed used relative with current = the file it
Op Mon, 12 Jul 2010, schreef Michael Schnell:
On 07/12/2010 08:12 AM, Michael Van Canneyt wrote:
So for historical reasons, FPC is stuck with the 'in' clause, when in fact
it should
not exist in the first place.
It could be made useful when
You may be able to make it more usefull, but
On Mon, 12 Jul 2010, Michael Schnell wrote:
On 07/12/2010 08:12 AM, Michael Van Canneyt wrote:
So for historical reasons, FPC is stuck with the 'in' clause, when in fact
it should
not exist in the first place.
It could be made useful when
- it takes precedence above the search path
- can
On 07/12/2010 01:32 PM, Michael Van Canneyt wrote:
The cure is far worse than the problem, because it is still trying to
combine 2 systems that are basically incompatible.
Right you are. I was just trying to help ;).
-Michael
___
fpc-devel
Michael Van Canneyt schrieb:
The cure is far worse than the problem, because it is still trying to
combine 2 systems that are basically incompatible.
Bottom line is: don't use 'in' for the uses clause; use the command-line
option to specify the location of the sources.
Then we could start
On Mon, 12 Jul 2010, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
The cure is far worse than the problem, because it is still trying to
combine 2 systems that are basically incompatible.
Bottom line is: don't use 'in' for the uses clause; use the command-line
option to specify
In our previous episode, Hans-Peter Diettrich said:
Michael Van Canneyt schrieb:
The cure is far worse than the problem, because it is still trying to
combine 2 systems that are basically incompatible.
Bottom line is: don't use 'in' for the uses clause; use the command-line
option
Marco van de Voort wrote on Mon, 12 Jul 2010:
In our previous episode, Hans-Peter Diettrich said:
Michael Van Canneyt schrieb:
The cure is far worse than the problem, because it is still trying to
combine 2 systems that are basically incompatible.
Bottom line is: don't use 'in' for the
Jonas Maebe schrieb:
Furthermore, at least two of the users have already posted in this
thread saying that they use this functionality (both in FPC and in
Delphi). Therefore I don't think it is a good idea to remove or change it.
ACK. My concern is about new users with (possibly) new uses of
I know that the in filespec is part of the Delphi syntax, but what
is it really good for?
AFAIK it's not allowed to rename units this way, and since (currently)
only absolute filenames are implemented, I really wonder why FPC allows
to use it everywhere?
IMO the filespec should allow for
On Sun, Jul 11, 2010 at 06:47, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
I know that the in filespec is part of the Delphi syntax, but what is it
really good for?
AFAIK it's not allowed to rename units this way, and since (currently)
only absolute filenames are implemented, I really
Op Sun, 11 Jul 2010, schreef Hans-Peter Diettrich:
I know that the in filespec is part of the Delphi syntax, but what is it
really good for?
In my opinion, it is not usefull. I have never seen a clear description of
what the semantics should be, for example what happens if the code being
On 11 Jul 2010, at 15:47, Hans-Peter Diettrich wrote:
I know that the in filespec is part of the Delphi syntax, but what is it
really good for?
AFAIK it's not allowed to rename units this way, and since (currently) only
absolute filenames are implemented,
That is incorrect. Relative
11.07.2010 17:47, Hans-Peter Diettrich:
I know that the in filespec is part of the Delphi syntax, but what
is it really good for?
For specifying path.
This way you are able to prevent any ambiguity in which file will
actually be selected. Not sure how exactly this is implemented in FPC,
but
Am 11.07.2010 um 19:48 schrieb Daniël Mantione:
Op Sun, 11 Jul 2010, schreef Hans-Peter Diettrich:
I know that the in filespec is part of the Delphi syntax, but what is it
really good for?
In my opinion, it is not usefull. I have never seen a clear description of
what the semantics
Jonas Maebe schrieb:
AFAIK it's not allowed to rename units this way, and since
(currently) only absolute filenames are implemented,
That is incorrect. Relative file names do work. They are resolved
relative to the current working directory of the compiler.
So what's the current working
On 11 Jul 2010, at 23:55, Hans-Peter Diettrich wrote:
Jonas Maebe schrieb:
AFAIK it's not allowed to rename units this way, and since
(currently) only absolute filenames are implemented,
That is incorrect. Relative file names do work. They are resolved
relative to the current working
Jonas Maebe schrieb:
That is incorrect. Relative file names do work. They are resolved
relative to the current working directory of the compiler.
So what's the current working directory?
The current directory when the compiler was started. E.g.:
c:\pp\src ppc386 project\test.pas
-
60 matches
Mail list logo
