[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] building the Memory Browser and Traditional Renderer
|
John
By the way I agree with the philosophy of
"0" warnings. Not so much in JAVA but
certainly in other languages I have been
burned badly by warnings. Ignore them at
your peril. When I first started working
on DSF and JAVA I got the advice that JAVA
warnings are never fatal or bad just
informational. But I have just not been able to
shed the OLD SCHOOL mentality of
mine.
So thanks for the effort here. I spent
alot of time getting rid of a lot of warnings in DSF
but they keep coming back for
more.
Randy
Yes. I sent various emails on the subject. It's my belief that our
plugins should generate zero warnings, and the memory projects have been set up
to try to ensure that (now that i removed all warnings). Whatever warnings (now
errors) you are seeing should be fixed, not ignored. One such issue was
reported this morning and fixed, and it was due to a subtle difference between
Canvas on linux and Windows that I was not seeing. I'll be happy to investigate
and fix any other issue you are seeing.
John
At 02:40 PM
5/10/2010, Rohrbach, Randy wrote:
Content-Class:
urn:content-classes:message
Content-Type:
multipart/alternative;
boundary="----_=_NextPart_001_01CAF078.A75F9926"
Folks
I just updated my
Open Source Reference CDT developmemnt space to all
M7.
I needed to reset the build
options errors/warnings for the MemoryBrowser and
TraditionalRenderer to the defaults in order to get them to build. I have not
made
any changes to these components. There were certain
specifications which were
forcing errors where they used to
just be warnings.
I have seen
some emails ( but not followed to closely ) concerning errors
and
warnings changes.
Has anything been changed for these
components.
Thanks for the
info.
Randy
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
