15.01.2010 10:50, Florian Klaempfl:
What's the point of being so carefull about unreadable PPUs?
Simply because it means that something really strange happened. Maybe it
is only a wrong compiler version but it could be also a corrupted file
system and then starting to delete files is really
On Fri, 15 Jan 2010, Nikolai Zhubr wrote:
15.01.2010 10:50, Florian Klaempfl:
What's the point of being so carefull about unreadable PPUs?
Simply because it means that something really strange happened. Maybe it
is only a wrong compiler version but it could be also a corrupted file
system
15.01.2010 14:12, Michael Van Canneyt:
Ok, maybe some command-line option could be usefull to explicitely
allow such PPU overwriting?
-B should do that.
It does not actually, I've just checked.
If I explicitely ask to compile the unit for which a damaged PPU file
does exist then no problem
Hello people,
I've discovered that (at least on win32) the compiler (2.2.2 and 2.4.0)
refuse to overwrite an invalid PPU file. It just stops.
One typical case is when PPU creation had previously failed due to disk
problems (e.g. out of room) or compilation abort, whatever, resulting in
Nikolai Zhubr schrieb:
Hello people,
I've discovered that (at least on win32) the compiler (2.2.2 and 2.4.0)
refuse to overwrite an invalid PPU file. It just stops.
One typical case is when PPU creation had previously failed due to disk
problems (e.g. out of room) or compilation abort,
I don't think that people will be happy if the compiler just deletes
their ppus if it can't read it for any reason. The compiler cannot know
if it can recreate the ppu when it deletes it.
Can't it just be made to treat a damaged/unreadable ppu in the same way
as an outdated or incompatible
Nikolai Zhubr schrieb:
15.01.2010 0:01, Florian Klaempfl:
I don't think that people will be happy if the compiler just deletes
their ppus if it can't read it for any reason. The compiler cannot know
if it can recreate the ppu when it deletes it.
Well, when a user asks compiler to compile,
