Markus wrote:
Naive question:
Should/can add we a test in the (G)makefile and disable certain gcc versions
to avoid too many "bug" reports?
This report is strange - first killed by Berhard, then reopened by Markus.
Could you take a look and tell me what to with it?
Thanks,
Maciek
-------------------------------------------- Managed by Request Tracker
On Tue, Sep 20, 2005 at 09:37:26AM +0200, Maciek Sieczka via RT wrote:
Markus wrote:
> Naive question:
> Should/can add we a test in the (G)makefile and disable certain gcc versions
> to avoid too many "bug" reports?This report is strange - first killed by Berhard, then reopened by Markus.
Could you take a look and tell me what to with it?
If I recall correctly, when I participate in such a discussion this was
about reports involving C++ and a "new"---at the time--- gcc(1) line having
some problems since C++ handling had changed.
What to do about this is typically an engineering decision, so it is not
mine.
FWIW, my personal options are :
1) Do not use C++;
2) Filter pb reports at arriving (don't store them inconditionnally)
to detect real problems with the code (portability---a filter on
the compiler version may hide real problems) and to discard user
side problems;
3) When the toolchain is at fault, provide hints in the building
documentation; simpler work around is to explicitely say that these
versions of tools are not supported.
(indeed, treating pb reports at arriving takes less time than pruning
afterwards).
It seems you are already discussing about your bug tracker (say this is
another option to 2). For 1), code exists in GRASS GPL so you are
unlikely to drop it soon. The simpler is to not let it get in 
For 3) this takes some time and this is always the problem.
But once more I have nothing to say about your way. If you are waiting
after me, between others, to decide about what to do with this bug
report, _for me_ (I'm not a GRASS GPL user), simply discard it since
problems discussed then are less frequent now (gcc(1) has evolved) and
the problems to address are more general and you are already discussing
these options (bug tracker should hold only hard facts).
Cheers,
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.org/ | http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C