 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / CodeWarrior / March 2004Cocoa in CodeWarrior or Xcode?
We plan on writing a complete new X-Platform application based on a bunch of shared libs written in C++. Apple suggested that we use Xcode and cocoa. After doing some testing we came to the conclusion that Cocoa is a powerful tool but Xcode is giving a lot of problems. According to my testing, you can not use partial pathnames in Xcode which means we would have to change a zillion files to get all the C++ code to compile. Is this the case or did I overlook something? We tried to use the C++, Mach-O plug-ins that are compiled in Codewarrior. They seem to work but we can't debug them properly because Xcode debugger just displays assembler. Is there a trick to use the xSym files generated by Codewarrior in Xcode? We are now looking at creating a Cocoa app in Codewarrior but I do not know if that is a good idea. Is it better to just use the Powerplant X framework which is i.m.h.o. a bit premature? All help appreciated, Bernard > We plan on writing a complete new X-Platform application based on a > bunch of shared libs written in C++. Apple suggested that we use Xcode [quoted text clipped - 11 lines] > Is there a trick to use the xSym files generated by Codewarrior in > Xcode? Don't think so, but if you have CW9, you can set it to create the STABS info that Xcode wants. Fred > We are now looking at creating a Cocoa app in Codewarrior but I do not > know if that is a good idea. Is it better to just use the Powerplant X > framework which is i.m.h.o. a bit premature? > > All help appreciated, > Bernard >According to my >testing, you can not use partial pathnames in Xcode which means we >would have to change a zillion files to get all the C++ code to >compile. Is this the case or did I overlook something What do you mean by partial pathnames? What are you trying to do? Maybe there is a different way to do what you want here. > What do you mean by partial pathnames? What are you trying to do? Maybe > there is a different way to do what you want here. We use a lot of X-Platform C++ code that is currently compiled as different plugins. All of these files include headers with partial pathnames e.g. in am_except.cpp you would find: #include "base/base.h" #include "base/basetrace.h" All of the code is structured like this: .../src/base/adt/am_except.cpp .../src/base/adt/amstream.cpp .../src/base/com/comexcpt.cpp ../src/chart/..... There are many other files like this. All header files are sitting in subfolders of inc e.g.: .../src/inc/base/base.h .../src/inc/cie/cietrace.h In a Codewarrior project you would just specify in the Project Access Paths {Project}.../.../src/inc and everything works fine. I tried using Source Trees in Xcode but that just won't work. Is there a solution? Bernard > > What do you mean by partial pathnames? What are you trying to do? Maybe > > there is a different way to do what you want here. [quoted text clipped - 18 lines] > I tried using Source Trees in Xcode but that just won't work. > Is there a solution? Project menu -> get info -> styles tab in the drawer there is a folder titled general, one of the items inside is "search paths" This could be what you are looking for. Fred >> > What do you mean by partial pathnames? What are you trying to do? Maybe >> > there is a different way to do what you want here. [quoted text clipped - 23 lines] >"search paths" >This could be what you are looking for. I think so. I think you would set the header path to .../src/inc in this case. Good Luck! > We plan on writing a complete new X-Platform application based on a > bunch of shared libs written in C++. Apple suggested that we use Xcode [quoted text clipped - 4 lines] > would have to change a zillion files to get all the C++ code to > compile. Is this the case or did I overlook something? It's hard to tell from your posting what you mean by "partial pathnames." From your statement that you would have to change a lot of code, I'm guessing that maybe you mean partial pathnames in #include statements, along the lines of: #include <sys/time.h> Is this what you mean? If so, you should be able to do this with Xcode. Actually it is an issue of whether gcc can use these pathnames, and I am sure that it can. Maybe in your tests you hadn't set the root directory of your header hierarchy in the search path for includes. Look at your target settings, under the category "Search Paths" and it should be obvious what to do. Or maybe you meant something else, in which case I think we need an example. - Dennis D. > We plan on writing a complete new X-Platform application based on a > bunch of shared libs written in C++. Apple suggested that we use Xcode > and cocoa. No surprise there. :) > We tried to use the C++, Mach-O plug-ins that are compiled in > Codewarrior. > They seem to work but we can't debug them properly because Xcode > debugger just displays assembler. > Is there a trick to use the xSym files generated by Codewarrior in > Xcode? I don't understand, you built something with CW and then you're trying to debug it with XCode? Why not just debug it with CW? XCode does not understand xSym files. > We are now looking at creating a Cocoa app in Codewarrior but I do not > know if that is a good idea. I wouldn't use CW 8 for Cocoa development, but I would use CW 9. >We plan on writing a complete new X-Platform application based on a >bunch of shared libs written in C++. Apple suggested that we use Xcode [quoted text clipped - 11 lines] >Is there a trick to use the xSym files generated by Codewarrior in >Xcode? You need to have the plugins generated with Full STABS information, with 8.3 that would be our version of the Apple linker and with CW 9 just turn this setting on for the debug target. (be sure they have the correct naming for a debug version too) >We are now looking at creating a Cocoa app in Codewarrior but I do not >know if that is a good idea. We are very good with Cocoa there should not be any problem with using CodeWarrior we do objective C and objective C++. > Is it better to just use the Powerplant X >framework which is i.m.h.o. a bit premature? It is a first release but it isn't premature, just not fully matured. Still it does have a lot of adapability with it. Bottom line is this isn't CW = C++ and XCode = Cocoa you can do Cocoa and use interface builder just fine with CodeWarrior 9.1 Ron  SignatureMetrowerks, maker of CodeWarrior - "Software Starts Here" Ron Liechty - MWRon@metrowerks.com - <http://www.metrowerks.com> I've developed a substantial body of work in Cocoa with CW, using a common c++ core that runs on Windows and PocketPC as well. CW8 was a bit painful but 9 is fine. I think it is a bit early to use PPX and I still think Cocoa apps have a slight edge over Carbon apps (eg: file open dialog behaviour) although I've not done enough Panther work to tell if that is still the case in 10.3 SignatureAndy Dent BSc MACS AACM OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows PP2MFC - PowerPlant->MFC portability http://www.oofile.com.au/ > We plan on writing a complete new X-Platform application based on a > bunch of shared libs written in C++. Apple suggested that we use Xcode > and cocoa. For some X-platform C++ work we did, we found that the Objective-Cism's of Cocoa were not terribly compilable for Windows, so we did not go that route. In the end, we used CodeWarrior to create a cross-platform non-GUI code base inside a Shared Library/DLL, which we accessed with a separate thin GUI application. Currently, RealBasic has been wonderful for fast X-platform GUI development (very similar to Visual Basic's GUI development abilities) and talks to our DLL's. However, by having our code separated out as it is, we could create a different GUI later, say using Java, or if we wish to separate the GUI's out per platform, we could use InterfaceBuilder for the Mac, and say Visual C# for Windows. Good Luck, Jonathan Hoyle Gene Codes Corporation > We plan on writing a complete new X-Platform application based on a > bunch of shared libs written in C++. Apple suggested that we use Xcode > and cocoa. Take a look at Whisper, <http://sourceforge.net/projects/whisper2/>, a modern, free (zlib/libpng license), cross-platform C++ framework. It is a better design than wxWindows. > > We plan on writing a complete new X-Platform application based on a > > bunch of shared libs written in C++. Apple suggested that we use Xcode [quoted text clipped - 4 lines] > > It is a better design than wxWindows. I'm sure that David is correct, and that Whisper is superior to wxWidgets (formerly wxWindows). However, looking at the SourceForge project, it sure looks like Whisper is effectively moribund -- no changes in over two years. For me at least, this rules it out. On the other hand, wxWidgets seems extremely active.... EO > However, looking at the SourceForge > project, it sure looks like Whisper is effectively moribund -- no > changes in over two years. For me at least, this rules it out. On the > other hand, wxWidgets seems extremely active.... It's not moribund because I am working on it in my spare cycles (and some others are), but it's slow, because I don't hav emany spare cycles. wxWindows has several major problems that I am not willing to overlook. What is wxWidgets? meeroh SignatureIf this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist> > wxWindows has several major problems that I am not willing to > overlook. my biggest complaint is that they use ms-windows idioms everywhere, which i consider suboptimal. "everything is a window" is a ridiculous abstraction. > What is wxWidgets? it's what happens when The Long Arm Of Microsoft descends on a perfectly harmless open-source project and "persuades" the authors to rename it. i haven't been following all the particulars, but i think ms gave julian smart and the rest of them a little bit of money to register a new domain name and do all the other tedious things it takes to rename a project of that size. > > wxWindows has several major problems that I am not willing to > > overlook. > > my biggest complaint is that they use ms-windows idioms everywhere, > which i consider suboptimal. "everything is a window" is a ridiculous > abstraction. My biggest problem is that IIRC the widgets are drawn by the framework rather than by the OS, resulting in subtle and annoying differences from the OS behavior. meeroh SignatureIf this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist> > I'm sure that David is correct, and that Whisper is superior to > wxWidgets (formerly wxWindows). However, looking at the SourceForge > project, it sure looks like Whisper is effectively moribund -- no > changes in over two years. For me at least, this rules it out. On the > other hand, wxWidgets seems extremely active.... The .zip "released files" is old, but the CVS is new. <http://sourceforge.net/cvs/?group_id=14021> and: <http://cvs.sourceforge.net/viewcvs.py/whisper2> |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.