Am 01.10.2010 18:51, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
Then what about moving those variables to the units where they belong?
Huh? Wasn't this exactly what I did in the NoGlobals branch?
I'm sorry... I didn't take a look at your branch, so I based my mail on
the knowledge I
Sven Barth schrieb:
Then what about moving those variables to the units where they belong?
Huh? Wasn't this exactly what I did in the NoGlobals branch?
That might be a starting point of which the solution might be easier
applied to trunk (not only in the sense of merging, but also in the
se
Michael Van Canneyt schrieb:
Every external tool has to drag in all the units, that initialize the
used global variables, regardless of their placement in globals.pas or
other units. Consequently all global variables should reside in those
units, that contain their initialization code. Doing s
Am 01.10.2010 09:49, schrieb Hans-Peter Diettrich:
Michael Van Canneyt schrieb:
He meant variables that are not part of an object, but declared as a unit
variable. If you put all such 'global' variables in 1 unit, you do
drag in all the original units, if the variables are typed.
Every extern
On Fri, 1 Oct 2010, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
He meant variables that are not part of an object, but declared as a unit
variable. If you put all such 'global' variables in 1 unit, you do drag in
all the original units, if the variables are typed.
Every exter
Michael Van Canneyt schrieb:
He meant variables that are not part of an object, but declared as a unit
variable. If you put all such 'global' variables in 1 unit, you do drag
in all the original units, if the variables are typed.
Every external tool has to drag in all the units, that initiali
On 2010-09-30 21:21, Andrew Brunner wrote:
2010/9/30 Adem:
It is only more logical/sensible to bring together all these
one-instance global objects into a one-instance global object, instead of
having them scattered all around the place.
I hope you are joking ...
I have read the above sente
Am 30.09.2010 21:06, schrieb Hans-Peter Diettrich:
> Jonas Maebe schrieb:
>
>> The basic problem is that his rewrite made ppudump dependent on the
>> code generator, not that ppudump's independence of the code generator
>> is enforced by the build system.
>
> Then *ppudump* must be hacked further
Jonas Maebe schrieb:
The basic problem is that his rewrite made ppudump dependent on the code
generator, not that ppudump's independence of the code generator is
enforced by the build system.
Then *ppudump* must be hacked further, since the currently present
workarounds (not using symconst,
Jonas Maebe schrieb:
That, it turned out that ppudump wasn't as independent as had been
thought?
The compiler doesn't think, it just gives an error when a unit is not
found.
Consequently the compiler can not know about the reasons of such
dependencies, and can not be used to judge what's
Jonas Maebe schrieb:
Next I'll move ppudump into the compiler, according to Adem's
suggestion, so that the dependency show stopper goes away.
The basic issue is that the functionality ppudump happens to depend on
must not depend on the code generator. The current build system enforces
this r
2010/9/30 Adem :
>>>
>>> It is only more logical/sensible to bring together all these
>>> one-instance global objects into a one-instance global object, instead of
>>> having them scattered all around the place.
>>
>> I hope you are joking ...
>
> I have read the above sentence (of mine) a few tim
On 2010-09-30 20:56, Florian Klämpfl wrote:
Am 30.09.2010 19:53, schrieb Adem:
It is only more logical/sensible to bring together all these
one-instance global objects into a one-instance global object,
instead of having them scattered all around the place.
I hope you are joking ...
I have r
Am 30.09.2010 19:53, schrieb Adem:
> On 2010-09-30 06:59, Florian Klämpfl wrote:
>> Am 30.09.2010 19:12, schrieb Adem:
>>> On 2010-09-30 19:39, Michael Van Canneyt wrote:
If you want to move the *global variables* (as in: unit scope)
CExportLib,ExportLib to globals, you must add export
On 2010-09-30 06:59, Florian Klämpfl wrote:
Am 30.09.2010 19:12, schrieb Adem:
On 2010-09-30 19:39, Michael Van Canneyt wrote:
If you want to move the *global variables* (as in: unit scope)
CExportLib,ExportLib to globals, you must add export to the globals unit.
Not only do I think they sh
Am 30.09.2010 19:12, schrieb Adem:
> On 2010-09-30 19:39, Michael Van Canneyt wrote:
>> If you want to move the *global variables* (as in: unit scope)
>> CExportLib,ExportLib to globals, you must add export to the globals unit.
> Not only do I think they should be moved to globals.pas, I also thin
On 2010-09-30 19:39, Michael Van Canneyt wrote:
If you want to move the *global variables* (as in: unit scope)
CExportLib,ExportLib to globals, you must add export to the globals unit.
Not only do I think they should be moved to globals.pas, I also think
they should be fields/properties/methods
On Thu, 30 Sep 2010, Adem wrote:
On 2010-09-30 18:07, Michael Van Canneyt wrote:
Actually, if I were DoDi, I'd probably bring all those units (that do
nothing but declare various types and constants) in the uses secions of
globals.pas into globals.pas. I don't see why bringing together all t
On 2010-09-30 18:07, Michael Van Canneyt wrote:
Actually, if I were DoDi, I'd probably bring all those units (that do
nothing but declare various types and constants) in the uses secions
of globals.pas into globals.pas. I don't see why bringing together
all the globals together should make eve
On Thu, 30 Sep 2010, Adem wrote:
On 2010-09-30 16:07, Jonas Maebe wrote:
On 30 Sep 2010, at 14:43, Adem wrote:
On 2010-09-30 15:03, Jonas Maebe wrote:
And the reason I said that is because Hans-Peter's wants to move it
inside the compiler so that making ppudump depend on the code generato
On 2010-09-30 16:07, Jonas Maebe wrote:
On 30 Sep 2010, at 14:43, Adem wrote:
On 2010-09-30 15:03, Jonas Maebe wrote:
And the reason I said that is because Hans-Peter's wants to move it
inside the compiler so that making ppudump depend on the code
generator would no longer break the build.
On 30 Sep 2010, at 14:43, Adem wrote:
On 2010-09-30 15:03, Jonas Maebe wrote:
And the reason I said that is because Hans-Peter's wants to move it
inside the compiler so that making ppudump depend on the code
generator would no longer break the build.
The basic problem is that his rewrite ma
On 2010-09-30 15:03, Jonas Maebe wrote:
And the reason I said that is because Hans-Peter's wants to move it
inside the compiler so that making ppudump depend on the code
generator would no longer break the build.
The basic problem is that his rewrite made ppudump dependent on the
code generato
On 30 Sep 2010, at 13:39, Adem wrote:
it's not clear to me why ppudump must be a strictly independent
stand-alone executable.
I did not say that it must be a stand-alone executable. I said that it
must not depend on the code generator (whether it's inside or outside
the compiler is irrel
On 2010-09-30 12:38, Jonas Maebe wrote:
The basic issue is that the functionality ppudump happens to depend on
must not depend on the code generator. The current build system
enforces this rather strictly. Removing the check from the build
system so that you can break this separation of concer
On 30 Sep 2010, at 11:40, Hans-Peter Diettrich wrote:
Next I'll move ppudump into the compiler, according to Adem's
suggestion, so that the dependency show stopper goes away.
The basic issue is that the functionality ppudump happens to depend on
must not depend on the code generator. The c
Today I provided two new patches for old issues. One covers the
preprocessor, which does not even compile in the trunk version (#16888).
The other one addresses the initialization of the class type variables
for node classes (#17516). Now I hope that these fundamental patches
will be applied so
27 matches
Mail list logo
