Slashdot Mirror
Competitive Cross-Platform Development?
Avalonia asks: "I work for a software company in the oil and gas exploration industry with a software development team of seven. Our software and development environment is cross-platform on Solaris, Irix, Linux and Windows. Most of our customers are on Solaris and Irix 64-bit systems, but Linux and Windows are increasingly important. Our environment is based around an elaborate command-line system of Makefiles controlling four different compilers (gcc 3.1, Sun Forte, Irix MIPSpro and Visual C++ 7). Needless to say, maintaining this system and producing modern multi-threaded C++ that will go through the four build systems is time-consuming in the extreme. A large proportion of our time is spent finding C++ code that just works rather than being creative and competitive with new functionality. What tools and strategies can we use to increase our productivity and regain our competitive advantage, without going for Windows only?"
"Our recent single-platform competitors (Windows only) can seriously outrun us in terms of productivity by using a single modern IDE development environment - such as C++ builder or Visual Studio - although we can scale onto larger multiprocessor Unix systems. With Windows 64-bit imminent we may lose our 'big-iron' scalability advantage. Java is not currently an option for the high-performance numerical and immersive graphical aspect of our applications."
I would suggest first using gcc on all UN*X platforms, and also trying out something like ant instead of the various forms of make you're dealing with now.
Also, have you considered using a library like Qt to handle most of the porting details? It's not free, but it is good if you can deal with it's oddities (I personally consider preprocessing to be evil).
Good luck.
-30-
In defense of my previous post:
As for graphics, there is a QT binding for perl that will allow you to do cross platform GUI work (and it looks nice, too)
As for speed, making C/C++ plugins for perl is not hard, and if you can break out your high-speed numerical pieces into small bits of code, it's relatively easy to call them from perl.
That said, perl isn't that slow. After you break out a few critical routines into their own XSUB modules, I bet you'd be surprised how fast perl is.
Also, perl 5.8 has very good threading support, and it isn't a global mutex around the interpreter like it is with some other interpreted languages.
Have you looked at Qt? It supports all the platforms you are developing for. It is primarily a platform independent GUI toolkit, but it also got a lot of other stuff like container classes (if you for some reason won't use stl), thread support, sql classes, xml classes and socket classes, all which are platform independent. It is not only just a portable GUI toolkit, I think it is the best GUI toolkit there is. I recommend it even if you're writing for Windows only. If you think of Qt more as a platform than a GUI toolkit, writing applications that run on multiple platforms (with native speed) may be easier than you think. (I'm not an employee of trolltech, although I am wearing a Qt t-shirt as I write this :)
You're joking, right? Perhaps I'm a little behind the times, but I was under the impression that GCC used a register based architecture where VC++ uses a stack based architecture. While GCC might spit out some average performing code with the default options, using -O3 will produce very fast running code. I've compared the performance of code compiled with GCC vs. the same program written in assembler, and at its best, GCC is only 50% slower than hand coded assembly, which is very good considering that some very well respected compilers will produce code that is 10 times slower than hand coded assembly.
I've also looked at the assembly language output of VC++, and it's a joke. VC++ often inserts large sections of extraneous instructions into the code. I've managed to follow function calls in VC++, and it is not uncommon for a function call to have prolog and epilog code of several dozen instructions. Interestingly, GCC uses a register based schema, and I can actually follow the code pretty easily, in spite of the fact that it uses the AT&T syntax. GCC just produces cleaner code.
The society for a thought-free internet welcomes you.
This stuff is done for real. At IBM I worked on a very large project that compiled on AIX (several distinct versions that we were sensitive to) Solaris, Windows NT, Linux, HPUX, and supposedly OS/400 although I never actually built the OS/400 piece nor have I seen it operate. First things first, you need good coding conventions, don't let some punk break them either. Secondly you have to design some abstractions and build some foundation classes; or buy a really good set or downlaod some good free ones, I've heard positive things about ACE. This is mostly a problem with windows any more, back a few years you might support win16, win32, PM, and UNIX now it's pretty much just POSIX and Windows. You need to abstract the machine stuff out. Threads, possibly strings and such (Unicode vs. non-unicode..) possibly basic types (big endian vs. little) networking code.. A rule of thumb is that on this kind of project you should never talk to the OS directly without something in between, it's a huge effort to make that OS abstraction layer or learn the ins and outs of an off the shelf one but it's worth it, even if you pay with a little performance. Nothing sucks more than coding away on AIX building some cool classes and adding some cool new stuff, then checking it in and finding that it doesn't compile on any other platforms.. and you've got to figure that crap out ASAP to make a deadline. If you build one from scratch, as IBM usually does or did, you can tune some things for your application; your OS abstraction layer can be a great "helper" or "utility" layer.
Typically well coded C and C++ can go from compiler to compiler pretty easily. Then you can use Pro64 on Mips, ACC on sparc, Intel C on Windows for performance critical portions of code. You have to be smart about it though and use some good conventions. The biggest rule would be avoid MS Visual Studio which is by far the most non-standard setup out there and if you do use it don't use their projects unless you have to. Some good make files with some good rules can help make this pretty easy. I don't know why more people don't do it but look at the Linux kernel's rules file. I have a Rules.make that I've built up and it includes things like different options for debug builds, profiled builds, and optimized builds, sets up some common rules for compiling C++ code and C code and what have you. My makefile include that file and then they are usually pretty short, generally not much more than a list of .cxx files and a library name.
Then it's easy to make sweeping changes too. I think a good build
system, one that will last should usually take a day or two to kind of
put together pretty early on in a project, unless you can carp some
good stuff from another project. The goal is a flexable and reliable
build system that you don't have to worry about. Far too often people
start cobbeling a build system together and then after 6-9 months it's
broken and britle and hard to change because so many things have been
changed and added through out the project. Put some effort in up
front, consolidate your rules in to one place, use some environment
variables to control some build switches. Use some shell scripts to
figure out various things, not hundreds of lines of Bourne shell code,
just little bits. Do this until AAP is ready and rocking and then use
that. Also, if it needs to be said, use GNU Make; it runs damn near
everywhere and it's pretty good at what it does the 15 minutes it
takes to learn it will save you hours and even days worth of time in
the long run.
I'm a huge advocate of a solid and strong build. Mozilla is a project that festered for weeks or maybe even months becuase you couldn't build the damn thing when it went open source. Building code is something that can be done so well by tools that if you're worried about it then you need to fix the build. Building software is hardwork so take the pieces you can out of the equation, the build is the first one.
Next, I assume you've abstracted out the GUI from the meat. If not, make this job one if you wish to have any chance in hell against your one platform competitors or even your mulitplatform competitors when you get down to it. View/Data Model and client/server: learn it, live it, love it. Or switch to a web based interface, lot's of people do it.
While we're on abstraction. If you guys are really serious then you're probably going to have machine specific components. Look at /usr/src/linux/include and /usr/src/linux/arch for a starting point of
reference. I would envision a project like this have a set of small Mips,
Wintel, Linux-x86, etc. directories. Everything else can probably be
compiled with GCC and then in those directories you'd have your
assembly and machine specific compiled code.
Lastly, you want to have a staged check in process. People hate not being able to commit code but at the same time you don't want them to commit code for real until it compiles on all of your platforms. Honestly, I don't know of a really good way to do this. Set up a build lab, do nightlies against the real code. Do nightlies against the "staged" code. Then have some kind of weekly merge meeting. That's how I've seen it, it's time consuming and somewhat painful. You bite off too much and you're spending a shitload of time merging stuff.