Here's a patch that implements the ouput as plain text for FPCunit.
Darius

Mailing lists / fpc-devel / 2006-08
14 messages · 6 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Here's a patch that implements the ouput as plain text for FPCunit.
Darius
Darius Blaszijk wroteHere's a patch that implements the ouput as plain text for FPCunit.
Thank you. Applied.
Michael.
Hi Michael,
Thanks, but I have a question.
Following the testreport patch, I have also a patch for the FPCUnitLazIDEIntf to make use of the plain text output. But I need to put defines around the new option, so people with an older FPC version do not get a broken tool. What defines would that be?
Darius
{$IFNDEF VER2_1}
// text output
{$ELSE}
// XML output.
{$ENDIF}But why would you want to do this ?
It seems to me the XML output is easier to use, since it is structured. What is the need to change it ?
I think it's best to discuss this before changing the mechanism...
Michael.
----- Original Message -----
.
.
Would this really provide the wanted behaviour?
I'd be very careful with using $IFDEF
VER<minimum_supported_version> rather than $IFDEF
VER<unsupported_versions>. The proposed version
would only work for trunk snapshots (and only for
sufficiently recent ones, of course). Any time a
new release based on trunk is made available,
this would stop working (and I doubt that anybody
would remember to change it at that time). My
recommendation would be to use either:
{$IFDEF VER2_0}
// XML output only
{$ELSE}
// text output allowed
{$ENDIF}(if nothing older than 2.0 is supported anyway -
I guess this is the case here) or possibly:
{$IF defined(VER2_0) or defined(VER1)}
// XML output only
{$ELSE}
// text output allowed
{$ENDIF}Tomas
I would like to use it like this;
// XML output.option
{$IFDEF VER2_1}
// text output option
{$ENDIF}So I would only include the code if the minimum version is supported. IIRC this define will stay there even when new releases are made right? I think this way nothing would be broken. The define would eventually be removed once Lazarus proceeds to 2.2 FPC version but would never hurt keeping the define.
Darius
I would follow Tomas suggestion.
{$IFNDEF VER2_0} is much better, also seen our experience with 1.0.x to
2.0.0 experience.The fpc team created betas for fpc 2.0 which had the version 1.9.x. If you had used {$IFDEF VER1_1} to use some functionality only in svn trunk, then would have to change it to {$IFDEF VER1_9} for the time of betas and {$IFDEF VER2_0} after the release of 2.0.
If you make it {$IFNDEF VER2_0}, there is no need to change it after 2.2, the functionality will be available right away and the Lazarus team can do the clean up, after they made their release of fpc 2.2. If you use {$IFDEF VER2_1}, big chance the first release with fpc 2.2 will NOT include the plain text writer.
Vincent
I would like to use it like this; // XML output.option {$IFDEF VER2_1} // text output…
No. The meaning of VERx[_y[_z]] conditional
symbol is "this compiler's version is x[.y[.z]]".
So VER2_1 is only defined in FPC 2.1.x. Once a
new release is made from trunk, it will probably
become 2.2.0 or possibly 3.0.0, but certainly not
2.1.x.
I think this way nothing would be broken. The define would eventually be removed once Lazarus proceeds to 2.2 FPC version but would never hurt keeping the define.
Well, it wouldn't be broken, but it wouldn't keep
the plain text output feature either. ;-)
Tomas
also a patch for the
>> >> FPCUnitLazIDEIntf >> >> to make use of the plain text output. But
I need to put defines around
>> >> the new >> >> option, so people with an older FPC
version do not get a broken tool.
behaviour?
> I'd be very careful with using $IFDEF > VER<minimum_supported_version> rather than
$IFDEF
> VER<unsupported_versions>. The proposed
version
> would only work for trunk snapshots (and only
for
> sufficiently recent ones, of course). Any
time a
> new release based on trunk is made available, > this would stop working (and I doubt that
anybody
anyway -
----- Original Message ----- From: "Michael Van Canneyt" To: "FPC developers' list" Sent:…
I can see that, but will your patch make plain text the default output for all lazarus related things ? If there are people out there who count on XML output, their stuff will be broken.
As Lazarus matures, backwards compatibility with Lazarus becomes more and more important :-)
If it's not the default option, this is fine, because the default remains backwards compatible...
Michael.
----- Original Message -----
----- Original Message ----- From: "Michael Van Canneyt" To: "FPC developers' list" Sent:…
I have the same issue... Chicken and Egg situation. Changes have been added to FPCUnit after FPC 2.0.2, but I need them now in Lazarus. I applied a few patches, but most of them I am holding off until after the the FPC 2.0.4 release. I figured the IFDEF's will be getting ugly in Lazarus, so only use the locally until 2.0.4.
Anyway, I did this in our local projects and then use the FPC202 or FPC202OrAbove defines...
{$if defined(ver1) or (defined(ver2_0) and (fpc_patch<2))}
{$fatal tiOPF2 requires at least FPC 2.0.2}
{$ELSEIF (defined(ver2_0) and (fpc_patch=2))}
{$DEFINE FPC202}
{$ELSE}
{$DEFINE FPC202OrAbove}
{$IFEND}Regards,
- Graeme -
Note that the ver1 check is afaik useless since ver1 doesn't support {$if defined
This brings me to another issue with $IF .... See my new post titled "$IF issues".
Regards,
Graeme.