Re: [wx-dev] Tomarro & MPW & Header Heirchy & Doxygen
Julian Smart
>Well, tomarro I'm going to start doing the (most likely major) changes in
>order
>to get wxWindows to link with MPW.
I haven't yet figured out what those changes are and I
think it could be too much change right now.
>Doxygen will work with what I have to do, so it's a matter of whether you
>want the changes
>and javadoc comments? Yes, or no?
No please...
>Just keep in mind that after the major changes over the next few days it's
>probably not going to be feasable again, and that I have a perfect time
>right now to do it.
>
>Anyway, thanks for the interesting discussion :).
>
>Ryan
>
>P.S. The types of changes I'll have to make are outlined here
>(http://lists.apple.com/archives/mpw-dev/2004/Jan/28/problemslinking.001.txt).
Not much use for me, it needs a logon.
Ryan, please don't do any changes just yet. We need
to have a WAY more conservative approach to modifying
CVS at the moment -- you're raising too many issues
for us to deal with and this has potential to cause
big disruption.
The priority is really to get CVS into a stable
state, not raise new or less important (e.g. documentation)
issues at this stage. Getting further compilers to
work with wxWindows should also not be a priority.
We have to calm wx-dev traffic down enough to have a hope
of getting 2.5.1 soon. We owe this to a lot of people.
Regards,
Julian
Ryan Norton
> Having #ifdeffed sections throughout the code just for having MPW support
> surely will not have my approval for carbon. As I don't have the resources
> to maintain classic you will have to discuss that with Dimitri once we
have
> done the split.
The only parts I know of that were ifdefed was the file stuff.
Anyway, I'll submit the ifdefed stuff as the patch, along with other things
I have questions about.
If you don't like ifdefed, then what would you prefer? I could for example
use native
mac functions for file i/o - but I'm not sure what you want....
Ryan
Dimitri
Hello,
> > I doubt this is true with the number of compilers/linkers we use. What's
> > the fix
> > you have? (I seen something with appending some letters to wx functions??)
>No, clearly it is not true with other compilers - however as mr. Austin
>pointed
>out, it's our problem, not the compiler's that we don't provide
>implementations
>for certain functions...
Could you give an example? We declare some function Foo which is called but
not implemented, and it works for all other compilers/linkers?
Or are you only referring to default constructors (as indicated in your
recent post)? There was an issue with this some months ago, I think the
warning was suppressed on MSVC for example.
Regards,
Dimitri
David Elliott
> Hi,
>
>> Do you have exceptions enabled in MrCpp? I did some quick googling
>> and
>> I got the impression that having exceptions on can cause link errors
>> like this for non-virtual funtions.
>>
>> wxWindows doesn't absolutely require exceptions or RTTI so make sure
>> they are both turned off and then see what happens.
> RTTI is turned off.
> MRC does have exceptions - but not in powerpc mode
> (I.E. for all intents and purposes it doesn't have exceptions :)).
>
Hmm. Okay.
>>>> Yes, but I looked at those changes and they are not at all
>>>> acceptable.
>>>> I believe you are just hiding some other problem.
>>> I know! I was hoping that someone would come up with something
>>> brilliant
>>> :).
>>>
>> That's kind of hard to do without having seen the patch. No harm in
>> putting half-tested code in the patch manager. I regularly do that or
>> post small patches to the list to get opinions from other developers
>> before committing.
> Sure :).
>
Great, I reviewed a few things and there's at least a couple things
(like adding const to a pointer taken in by a function which doesn't
modify it) that I think would make sense though I'd still want to make
sure it didn't break CW or GCC first.
Most of the abstract class stuff is not right at all though. I'm sure
there's some solution. Now that I know you actually got things to run
(albeit by taking a sledgehammer to the source code) I'm considering
downloading MPW myself and taking a whack at it.
>>
>>>> Hmm, interesting.
>>> Debugging the hash map/array stuff is a task nobody should ever have
>>> to do
>>> :).
>>> Not only this but in my expendature into MRC-ville I saw some dark
>>> places in wx that looked like they were... rather rushed :).
>>>
>> Well, an alternative viewpoint would be that they are rather complex
>> things and it's a pretty cool hack that they can be done at all.
> Very true - and some of my changes concerning wxFile were just as bad
> (MRC does not have non-stdio file i/o).
>
Yeah, I think as someone else mentioned, GUSI is the answer to this.
As for the list code it's actually gotten worse looking recently
because of all the std:: compatibility stuff. More of a comment on the
overall readability of STL code than on wxWindows.
>> This works for me:
>> perl -p -i -e 'y/\r/\n/' somefile
> Google for "flip" - it's EXCELLENT, and available for all platforms
> w/public
> domain source code - and it converts from/to all 3 types.
>
I'm a UNIX guy so I try to use what's available if possible. I've
heard of flip but just not needed it.
> I've thought about that too - have you been able to get bakefile to
> work
> on mac? If so how do you do it(I haven't had to compile bakefile...)?
>
I think the 0.1.2 release works if you have fink and have sourced its
init.sh. The CVS HEAD works on a stock OS X machine IF you have fink
and can properly run ./autogen.sh (under an environment with init.sh
sourced) and then you can run configure on any machine with or without
fink though if you have init.sh sourced I think it pick's up fink's
python. Hmm, maybe I'll build from an environment which did not source
fink's init.sh and make a .pkg out of it.
[snip]
> Sorry - you'll have to be patient - I have to go directory by
> directory reversing the newlines of all files while being careful I
> don't change the newlines of non-text files.
>
Does MPW have an option to write UNIX text files? I know CW does.
Probably the easiest thing to do is make yourself a list of files and
use it to convert the files back and forth. Or even easier, use a
different directory and use a classic Mac CVS client.
-Dave
Vaclav Slavik
> *sigh* it's *NOT* an old compiler :). My version of visual c++ is
> older!
But it seems from your description that it is even more broken than
MSVC6 (quite an achievement!).
> I think the problem dave has with this is that he wants link errors
> if you try to use the = op... There's really no way to do this
> cross-compiler-wise...
How comes all other compilers support it, then? Something is seriously
wrong with MPW's linker if it insists on having core for symbols that
are never used.
Regards,
Vaclav
--
PGP key: 0x465264C9, available from http://pgp.mit.edu/
David Elliott
> Ryan Norton wrote:
>> *sigh* it's *NOT* an old compiler :). My version of visual c++ is
>> older!
>
> But it seems from your description that it is even more broken than
> MSVC6 (quite an achievement!).
>
MPW is an older compiler just like OpenWatcom is an older compiler.
They might have been released more recently but they hadn't had any
changes for years. In that light it's not much of a surprise that it's
more broken than MSVC6. But if you think that's bad, try MSVC5
sometime.
>> I think the problem dave has with this is that he wants link errors
>> if you try to use the = op... There's really no way to do this
>> cross-compiler-wise...
>
> How comes all other compilers support it, then? Something is seriously
> wrong with MPW's linker if it insists on having core for symbols that
> are never used.
>
Yes, I don't like the idea of yet another busted compiler to support.
It's one thing on MSW where a lot of people are using Borland and MSVC6
and to a lesser extent OpenWatcom but it's quite another thing on Mac
where almost everybody is using CodeWarrior. In any case, I think my
GCC fixes are going to make this irrelevant.
-Dave
Ryan Norton
BTW to clarify the "big changes" statement I keep making - I don't
mean structural changes - I just mean a ton of compilation/linking fixes.
Sorry to scare everyone if you thought otherwise :).
Ryan
Stefan Csomor
> Well, the reason I'm trying to get MPW to work is because there is no
> other
> free compiler for mac os classic - and when I got it working I was hoping
> to
> take over
> maintainership of the classic port and contribute mostly to carbon - which
> looks like it needs it.
Having #ifdeffed sections throughout the code just for having MPW support
surely will not have my approval for carbon. As I don't have the resources
to maintain classic you will have to discuss that with Dimitri once we have
done the split.
I appreciate patches for carbon very much, but I don't want to have wild
commits in the code, as this will make the migration very difficult.
Best,
Stefan
Ryan Norton
> Hi
>
> if it is only the file i/o then I'm ok with that, as we don't have to
change
> that code often, still I'd give GUSI a try, perhaps it would resolve
things
> nicely.
>
As far as I know - there are a lot of places, in fact a TON of places where
the code simply assumes that "hey, if you're using a pre-OSX OS, you MUST be
using codewarrior!", and there are probably around 50 instances of this with
more popping
up every now and then. I am forced of course to change the ifdefs in those
places
(note that if at all possible I try to add rather then change).
That, with the file stuff, is all that is ifdefed to my recollected (and the
rawbmp.h
because MPW does not support the special stuff it does with templates).
Anyway, I hope those changes are ok with you. I will of course
make a patch for the stuff I'm not sure of.
Thanks,
Ryan
Ryan Norton
> to maintain classic you will have to discuss that with Dimitri once we
have
> done the split.
I'd be willing to maintain the classic port the way it is, so you may not
need to make
a change.
But if you do want to go through with the change I'd be willing to
contribute to classic
then also - probably not as much due to the convenience of the situation
though....
Ryan
Ryan Norton
> Is WXUNUSED not defined properly for MRC?
Nope! Just tested it and WXUNUSED works perfectly - all those
warnings (there's about 50 of them) are our fault :\.
Ryan
Stefa...@t-online.de
> You sure the operator= was not declared virtual in a base class? If so
> then the fix _might_ be to implement the operator= to call wxFAIL.
If it's a really old compiler, it probably has no default copy constructor
nor a default assignment operator, which C++ compilers are supposed to
generate automatically, so any (perfectly legal) use of them is going to
give you errors ...
Regards,
Stefan
Ryan Norton
>If it's a really old compiler, it probably has no default copy constructor
>nor a default assignment operator, which C++ compilers are supposed to
>generate automatically, so any (perfectly legal) use of them is going to
>give you errors ...
*sigh* it's *NOT* an old compiler :). My version of visual c++ is older!
Anyway, Stefan the issue here is about unimplemented functions, that is
functions
that are DECLARED but NOT IMPLEMENTED - namely the = operator.
David was just mentioning putting a fail in the ones that were declared.
I think the problem dave has with this is that he wants link errors if
you try to use the = op... There's really no way to do this
cross-compiler-wise...
it would be nice to have link errors but in all practicality a fail should
be stuck in...
Ryan
Stefa...@t-online.de
> more broken than MSVC6. But if you think that's bad, try MSVC5
> sometime.
Well, I'm using VC5 and it works rather nicely for wxWindows.
The only irritating thing is that with current default warning level,
it's giving tons of warnings about its _own_ header files when
compiling some of wxWindows' source files. ;-)
Regards,
Stefan
ABX
> Well, I'm using VC5 and it works rather nicely for wxWindows.
> The only irritating thing is that with current default warning level,
> it's giving tons of warnings about its _own_ header files when
> compiling some of wxWindows' source files. ;-)
I imagine this can be annoying. Did you tried something like
(if possible with VC5):
#if VC=5
#pragma warning NNN off
#endif
#include <windows.h> // or other header with problems
#if VC=5
#pragma warning NNN default
#endif
?
ABX
Ryan Norton
> MPW is an older compiler just like OpenWatcom is an older compiler.
> They might have been released more recently but they hadn't had any
> changes for years. In that light it's not much of a surprise that it's
> more broken than MSVC6. But if you think that's bad, try MSVC5
> sometime.
Well - to put this in a nice way it isn't quite correct. As I said
recently Apple added fairly nice template support to MPW recently
that should make it compatible with rawbmp.h, and I believe they
also added exceptions to powerpc mode...
> Yes, I don't like the idea of yet another busted compiler to support.
> It's one thing on MSW where a lot of people are using Borland and MSVC6
> and to a lesser extent OpenWatcom but it's quite another thing on Mac
> where almost everybody is using CodeWarrior. In any case, I think my
> GCC fixes are going to make this irrelevant.
Again, it's not broken! If you want to try it out for yourself - it's
actually a decent
compiler.
Ryan
Vaclav Slavik
> Again, it's not broken!
Shouting again and again that it is not broken won't change the facts.
Before you post another three emails claiming that it is not broken,
please have a look at your own patch "Changes required for MPW
compilation" and notice the comment that says "NOTE: FOR MGW
FUNCTIONS ----MUST---- HAVE IMPLEMENTATIONS OTHERWISE A LINK ERROR
WILL OCCUR!!!!".
Make up your mind, either the compiler isn't broken or these changes
are required for MPW compilation. It can't be both true at the same
time, as it seems is clear to everybody else after looking at the
patches and hearing about the operator= problem.
William Gallafent
Elliot that wrote this:]
> > MPW is an older compiler just like OpenWatcom is an
> > older compiler. They might have been released more
> > recently but they hadn't had any changes for years. In
> > that light it's not much of a surprise that it's more
> > broken than MSVC6. But if you think that's bad, try
> > MSVC5 sometime.
On Friday 30 January 2004 19:26, Ryan Norton wrote:
> Well - to put this in a nice way it isn't quite correct.
> As I said recently Apple added fairly nice template
> support to MPW recently that should make it compatible
> with rawbmp.h, and I believe they also added exceptions to
> powerpc mode...
According to the Apple Developer website, the most recent
version of MrCpp to be released was 5.0d3 (a pre-release
version ... no sign of a subsequent actual release!), in
November 2000. That's not very recent.
> > Yes, I don't like the idea of yet another busted
> > compiler to support. It's one thing on MSW where a lot
> > of people are using Borland and MSVC6 and to a lesser
> > extent OpenWatcom but it's quite another thing on Mac
> > where almost everybody is using CodeWarrior. In any
> > case, I think my GCC fixes are going to make this
> > irrelevant.
> Again, it's not broken! If you want to try it out for
> yourself - it's actually a decent compiler.
Make your mind up! The number of posts you've made over the
last few days explaining how to work around problems you had
compiling wx (not a particularly difficult piece of C++ to
compile) suggests otherwise.
For example, you wrote:
> MRC DOES NOT SUPPORT
> 1. TEMPLATE SPECIALIZATION
> 2. INTERNAL TEMPLATE CLASSES
> 3. TYPEDEF TYPENAME
> 4. DEFAULT TEMPLATE ARGUMENTS
> Add these to the list of things to watch out for -
> 1.
> array initialization lists -
> i.e.
> int myarray[3] = {3,3,3};
> is ok but
> int myarray[3] = {3,myint,3};
> is not (MRC only supports constant initializers)
Once you've got wxWindows up and running using MrCpp, I
suggest you try to compile the Boost C++ libraries
(http://www.boost.org/) and Blitz++
(http://www.oonumerics.org/blitz/) with it.
Both of these are a better test of whether or not it's a C++
compiler. Your statements above already suggest it isn't.
--
Bill Gallafent.