×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Competitive Cross-Platform Development?

Cliff posted more than 11 years ago | from the keeping-up-without-losing-compatibility dept.

Programming 411

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

411 comments

Might I suggest... (1, Insightful)

XaXXon (202882) | more than 11 years ago | (#4601853)

Perl? :)

Platform independent, it's highly creative, and damn if you can't prototype stuff quickly.

Re:Might I suggest... (-1)

Anonymous Coward | more than 11 years ago | (#4601875)

Python is better than perl. Especially with the NPNP addon.

Re:Might I suggest... (5, Insightful)

akookieone (530708) | more than 11 years ago | (#4601896)

Are you kidding me? They are building a real application that performs and does multi-threaded as only C++ can do. If you can't use java, what makes you think that perl, especially interpretted, would do the trick? Yeah, fine for prototyping, but how is this going to help?

Re:Might I suggest... (2, Interesting)

Anonymous Coward | more than 11 years ago | (#4601901)

Python [python.org] ? :)

Platform independent, it's highly creative, and damn if you can't prototype stuff quickly.

P.S. And you can actually understand the code months after you wrote it. ;)

Re:Might I suggest... (2, Funny)

SirSlud (67381) | more than 11 years ago | (#4601925)

LOL! Well, you didn't suggest Javascript, so I guess that counts for something.

Re:Might I suggest... (2)

EyesWideOpen (198253) | more than 11 years ago | (#4601930)

This would seem like a good solution on the surface of it but the 'immersive graphical aspect of our applications' that was mentioned may mean Perl is out of the question.

Of course I've never done any graphical programming in Perl (besides Perl/CGI) so I could be wrong depending on the nature of the GUI.

Re:Might I suggest... (0)

shepd (155729) | more than 11 years ago | (#4602000)

Not that it's particularly excellent, but PerlTk [perltk.org] does 100% of basic GUI functionality, but lacks a lot of "splash" and speed.

Re:Might I suggest... (1)

ArmorFiend (151674) | more than 11 years ago | (#4601985)

If they're worried about performance to the point where gcc ISN'T good enough on the various machines, then they're not going to goof around with interpreted languages, they'll be waaaaay too slow.

Lay off half your programmers, then invest the money you save in contracting for GCC optimizations on your oddball platforms.

Re:Might I suggest... (2, Insightful)

bomb_number_20 (168641) | more than 11 years ago | (#4601991)

I think the parent is a joke, but:

if all you have is a hammer, eventually everything begins to look like a nail.

Re:Might I suggest... (1)

Dan667 (564390) | more than 11 years ago | (#4602026)

I agree. I build on multiple platforms for a CAD system and use one set of perl code for all of them. Use ansi c for the heavy stuff. Works great

Re:Might I *STILL* suggest... (5, Interesting)

XaXXon (202882) | more than 11 years ago | (#4602036)

In defense of my previous post:

As for graphics, there is a QT binding for perl [infonium.com] 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 [perl.org] , and it isn't a global mutex around the interpreter like it is with some other interpreted languages.

Re:Might I suggest... (1, Insightful)

kryonD (163018) | more than 11 years ago | (#4602043)

Take it even a step further. Web base everything and ensure that your cgi cripts only produce HTML 1.0 compliant pages. You can of course go higher than 1.0, but then you start to get into the "What browsers do I support?" question.

Your code could indeed be written in perl, although I would recommend ANSI C or C++ for two reasons. #1 You are already familiar with the language and compilers. #2 You probably deal with large variable quantities of data that are processor intensive and would suffer from "script" style languages.

The beauty of this is you can now switch to only one compiler since the applications are only running on the web server. My programming shop is responsible for producing software that tracks and manages supply and maintenance in the Western Pacific for the Marine Corps. You may not have alot of customers who are running your software from a tent in the middle of BFE over an 8KBit pipe. But I'm sure web basing will still reduce the number of customer support issues that involve you going to the machine the software is installed on to see what the customer is talking about when he says, "I'm getting this strange error."

It worked wonders for our shop of 5 programmers

try (3, Insightful)

BigChigger (551094) | more than 11 years ago | (#4601860)

www.eclipse.org

I think it runs on several of the environments you mention. And I think there are C++ plugins for it.

BC

Re:try (0)

Anonymous Coward | more than 11 years ago | (#4601964)

>www.eclipse.org

These guys can't even do a website properly. Their top menu might be in HTML (which is good), but I can't read those 4px fonts (which is bad).

BTW I'm using Opera 6 on WinXP (I'm at work, don't start flaming me about "choosing WinXP"...)

Re:try (1)

Necroman (61604) | more than 11 years ago | (#4602072)

Eclipse is just an IDE, that is it. There are no compilers what so ever that go along with eclipse. And the CDT (c++) plugin for Eclipse is not the best thing in the world, but I have not used it in a while, so I can't say.

Try again.

gcc cross platform? (5, Insightful)

SirSlud (67381) | more than 11 years ago | (#4601868)

why all the different compilers?

Hrm, this seems too simple an answer, there must be something wrong with it .. but can't gcc cross compile? At least then you could dump alot of the compiler-specific scripting in your build procedures.

Re:gcc cross platform? (2)

tsetem (59788) | more than 11 years ago | (#4601969)

Along with GCC for cross-platform compatibility, look at using GLIBC to make sure the functions you expect to be there, are there for all of the platforms.

Haven't checked recently, but is CygWin still being maintained? If it is, then you have GCC available on all four of your platforms, along with the same development libraries and headers.

You may lose some of your "Big Iron" support since you are using GLIBC instead of the native libraries. (but I'm not an expert in this to know what kind of performance hit you may take).

Re:gcc cross platform? (4, Informative)

aridhol (112307) | more than 11 years ago | (#4602019)

You aren't necessarily using GLibC. GCC works just as well with other LibC implementations, so you can use your "Big Iron"'s own LibC and LibC++.

Re:gcc cross platform? (1)

SirSlud (67381) | more than 11 years ago | (#4602084)

Yes indeedie. Go gcc!

> He that breaks a thing to find out what it is has left the path of wisdom -- Gandalf the Grey

[cannot resist joke]
Like a cherry? Ahah! I always wondered why LotR fans were virgins well into life.
[/cannot resist joke]

Now mod me into the core of the earth; the pun was simply too juicy to ignore! :)

Re:gcc cross platform? (5, Informative)

ncw (59013) | more than 11 years ago | (#4602119)

We do exactly this in our main product (a control and monitoring system). It is about 300k lines almost evenly matched between C and C++. Portability was a major concern in its design - we've already had to port it from an obsolete platform!

We compile using gcc for unix (linux mostly) and Windows using mingw. We cross compile everything from linux and this all works from one Makefile. Recently we even managed to get the NullSoft NSIS installer working under Wine so we can make the install package under linux too.

Once we got all this ironed out we don't really have to worry which platform we are working on - "it all just works". Any developer can compile for every platform too.

We split the design into a server part and a client part. The server part doesn't do anything fancy but the client part of course interfaces with the user. We had flirtations with wxWindows [*]and GTK[*] as cross platform GUIs but in the end we decided to use SDL. SDL is very simple but it really works excellently - our application looks identical down to the last pixel on Windows and Linux. Of course we had to write our own windowing system but that is what C++ is for isn't it ;-)

[*] In our experience GTK doesn't work very well under windows, wxWindows is just too different on Windows/Unix and we couldn't (then) afford the licence fee for QT for commercial products. SDL seemed just the answer for us.

Gcc? (4, Insightful)

JanneM (7445) | more than 11 years ago | (#4601877)

Why not just use gcc for all four platforms? The sticking point would likely be Windows, but even if you elect to stay with MFC++ for Windows, you've reduced the incompatibilities from four to two different compilers.

Re:Gcc? (1, Informative)

Anonymous Coward | more than 11 years ago | (#4601941)

You don't want to use GCC if you can help it because it's performance is terrible. GCC is great for xplatform stuff, but for real power, native compilers spank it every time.

Of course, there is the extra effort of maintaining compatability, but the speed increase is definitely worth it.

[ custom app compiled with cc on solaris/sparc and aix/xlc was around 45-65% faster than gcc 2.95.1. There was a lot of data moving around, and not a lot of I/O or calculation. YMMV ]

Re:Gcc? (4, Informative)

Mitchell Mebane (594797) | more than 11 years ago | (#4601962)

custom app compiled with cc on solaris/sparc and aix/xlc was around 45-65% faster than gcc 2.95.1.

GCC 3.2 performs MUCH better.

Re:Gcc? (1)

robbo (4388) | more than 11 years ago | (#4602051)

All the same, I would at least dump VC on the windows platform and tell the client they need to move to a different os. Maintaining cross-compat between gcc, and the irix and solaris compilers shouldn't be too difficult (but to make your life easier, be sure to switch to gnu make on all three.)

Whatever you do, (and you've already said you're not), DON'T use gcc 2.x for C++ development.

Re:Gcc? Speed. (5, Informative)

for(;;); (21766) | more than 11 years ago | (#4602014)

gcc is built for portability, not speed. VC++'s code is faster, but has zero portability and its own magical, lsd-inspired "innovations." [" for(int i=0;in;i++); for(int i=0;in;i++); ? Why would anybody ever want to compile code like that?"] That intel compiler mentioned on /. a while back sounded fast; but the gcc-for-everything approach may not be best, if they find compiled java too slow.

Dear Slashdot, (-1, Offtopic)

PDHoss (141657) | more than 11 years ago | (#4601880)

I am really in the mood for a religious flamewar. What topic do you suggest? I was thinking along the lines of "what language is best?", but I am not so sure. What do you think?

PDHoss

Re:Dear Slashdot, (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4601933)

>I was thinking along the lines of "what language is best?"

For me it's either Color Basic (CoCo2) or Turbo-Pascal (PC/DOS). Then again Watcom C++ ain't bad either (PC/DOS).

I think I'm getting too old for this...

GCC (3, Informative)

captaineo (87164) | more than 11 years ago | (#4601885)

You can, with some loss of performance, use GCC on all of those platforms. That would cut out compiler quirks as a variable.

Don't write Makefiles yourself. Instead write a script that translates simple build rules (foo.cpp -> foo.o -> foo.exe) into a custom Makefile for each platform. I went this route after battling for years with complex Makefile rules that never quite worked.

Re:GCC (1)

sjh (29820) | more than 11 years ago | (#4601968)

Some loss of performance? Are you kidding? gcc
output is MUCH slower then Forte (I don't use
irix, but I imagine it's the same there). gcc
is a good IA32 compiler, but not so good on many
other systems.

Re:GCC (1)

SirGeek (120712) | more than 11 years ago | (#4601988)

Don't write Makefiles yourself. Instead write a script that translates simple build rules (foo.cpp -> foo.o -> foo.exe) into a custom Makefile for each platform. I went this route after battling for years with complex Makefile rules that never quite worked.

Why not use Automake and Autoconf ? Wouldn't that take care of some of the cross system problems ?

EXTREME! (-1)

MondoMor (262881) | more than 11 years ago | (#4601887)

time-consuming in the extreme


Whoa, dude! Slashdot's my source for extreme programming! Far out! ...

Jesus, I'm like a sponge for shitty marketing drivvel.

There was an ad for Visual Studio under the blurb. (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4601894)

How ironic.

(BTW, is there anything better than Visual Studio?)

Yes (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4601898)

Wait, no.

Different platforms.. different people (1)

1155 (538047) | more than 11 years ago | (#4601903)

Why not split the platforms, and hire a few more people? I know, I know, this doesn't seem feasible, right? But if you were able to split the code into what it would actually work on, say you have yourself and joe working windows, you guys just work on windows, and have all the code that works within that ide. Jan and Sue, with help from the janitor Steve, are all working on the irix side, etc, etc, etc. It would seem more feasible than actually working all these different platforms together at once? And what about mac, is there a demand for that as well? Would be a good time to look into it...

Re:Different platforms.. different people (2, Funny)

mxmissile (569819) | more than 11 years ago | (#4601978)

Read this [amazon.com] .

Re:Different platforms.. different people (1)

br0ck (237309) | more than 11 years ago | (#4602100)

The Mythical Man Month says that adding people to a project won't make development go faster due to additional overhead. However, sometimes the scope and requirements of a project sometimes dictate adding additional help. In this case, having one set of people, who are highly trained in coding and optimizations on their particular platform, do all of the platform specific work would alleviate the burden on the other part of the team and allow them to begin adding new features. The architecture team could prototype and develop new pieces, while the implementation teams hammer out the details on the target machines.

Re:Different platforms.. different people (1)

Neumann (240442) | more than 11 years ago | (#4602106)

He didnt talk about adding people to the end of a project to get it done on time. He talked about expanding the developer base because there is now extra work that needs to be done on an ongoing basis.

By your logic there should only be one programmer in the world, because adding any others would not get any more code written faster.

Qt (or maybe Java) (1)

Chuck Messenger (320443) | more than 11 years ago | (#4601904)

Qt is a great cross-platform C++ environment. It's a highly polished GUI framework, but also general-purpose. In terms of cross-platform C++ frameworks, I don't know of anything that beats Qt.

Another thought is Java, of course...

Re:Qt (or maybe Java) (0)

Anonymous Coward | more than 11 years ago | (#4602029)

"Java is not currently an option for the high-performance numerical and immersive graphical aspect of our applications."

Well, it's nice to know you're staying open-minded...

GCC/DJGPP (2, Informative)

maverickbna (578984) | more than 11 years ago | (#4601915)

gcc is cross-platform, can cross-compile to different platforms, and for those who feel the need to use Windows, gcc has been ported, to the ever-popular development suite called DJGPP.

GCC [gnu.org]
DJGPP [delorie.com]

Code Objectification (1)

Lemmeoutada Collecti (588075) | more than 11 years ago | (#4601928)

I would imagine that you could build a collection of libraries, using a well defined interface, with precompiled object code for each platform and tie into thiose in the mainline routines using late binding. The advantage is since you control all the libraries, the binding method can be abstracted by an API specific to your industry, and 'DLL Hell' avoided by proper planning.

This would allow smaller primary binaries, and would allow upgrading part of the project without changing the whole... also, the reusable functions can be tested using known results from other platforms.

The less you have to recompile for each change, the easier the Makefiles etc are to maintain.

Simple soloution (0)

Anonymous Coward | more than 11 years ago | (#4601929)

clr

...write portable code? (5, Funny)

jukal (523582) | more than 11 years ago | (#4601932)

...uhm...ahmmm...mmm. Dunno what to add.

Re:...write portable code? (2)

chennes (263526) | more than 11 years ago | (#4602118)

More difficult than you would like. Ever try to get something using templates to compile on those four platforms? I don't recommend it. If you are trying to get into the more complex things that you can do with C++, it's *very*, *very* difficult to write 100% portable code.

Drop the Solaris and IRIX compilers (1, Informative)

Anonymous Coward | more than 11 years ago | (#4601943)

Use gcc 3.x on Solaris, IRIX, and Linux. That way, you remove two vectors of incompatibility, and you only have to test UNIX and Windows for compatibility. And if you stick to standard C++, you shouldn't have very many problems with even that.

Of course, there are drawbacks. I doubt gcc's optimizer is as good as the native optimizers for the Solaris and IRIX compilers, for example. But you might want to try it anyway, and see if the performance hit you're taking is worth the hassle.

If you're daring, you could even try to replace Visual C++ on Windows with cygwin or ming. But don't try that until you're happy with the Solaris and IRIX solutions first.

Go client/server? (5, Informative)

WasterDave (20047) | more than 11 years ago | (#4601944)

I assume that most of your problems are in the GUI end of the equation - why not break the application into two bits? Put the numerical stuff on a grunty 8 way box, and cook up the UI with whatever language best suits the available (and hireable) skills and platform?

Communication between the two is probably best through SOAP, although to be honest I've not looked into this area for a long time. The GUI can still be built from Java (I believe Java has some reasonably fast OpenGL wrappers now), or look into wxWindows [wxwindows.org] using the existing C++ resource.

Dave

Mod parent up!!! (1)

FortKnox (169099) | more than 11 years ago | (#4602033)

Mod this up!

Maintain the server that does the complexities, and all you need is a Java client that talks to it. The Java client handles the multiplatforms, and the C++ backend does everything efficiently on a server.

JAVA (0, Funny)

Anonymous Coward | more than 11 years ago | (#4601947)


Java. Java, more Java.

www.sun.com

Java

I do the same (0)

Anonymous Coward | more than 11 years ago | (#4601952)

I have to support C++ on Windows, Solaris, Linux, HPUX, and AIX. I feel your pain :-) One thing that helps tremendously is something like tinderbox from the mozilla project. It does continous builds and integrates into the version control system so you can find out when someone broke the code quickly rather than the next day. Its also good to come up with a list of C++ features that you wont use. Mozilla.org has a list that you can adopt if you want, but its probably a little more draconian than you need. But do develop some sort of programming guidlines that say (you cant use c++ feature X).

Might I suggest.... (0, Flamebait)

mary_will_grow (466638) | more than 11 years ago | (#4601956)

Working for an industry that isnt helping to destroy the world?

Re:Might I suggest.... (0)

Anonymous Coward | more than 11 years ago | (#4601993)

>Working for an industry that isnt helping to destroy the world?

I'm confused. Are you talking about the oil companies or Microsoft?

Re:Might I suggest.... (1)

mxmissile (569819) | more than 11 years ago | (#4602016)

Although I agree with you 110%, this is a loosing battle in the economy state we are currently in.

Re:Might I suggest.... (2)

binaryDigit (557647) | more than 11 years ago | (#4602052)

And I assume that you walked to work, have a hamster run generator that's powering the computer that you posted on, don't use anything plastic or wear nylons or spandex?

I've done this! (5, Informative)

hajo (74449) | more than 11 years ago | (#4601961)

I've done something similar in a mixed environemnt. The way we set it up is to use java for GUI and logic development and then run a profiler against it and go native on those functions that needed it. These functions would be compiled into a library. (You'd be amazed how little of your code you need to optimize for huge performance gains!)
If I had to do it again I would do the same thing except I would use python as the 'main, relatively slow, easy to code and maintain' language.

Hajo

Python, Java, wxWindows (4, Informative)

g4dget (579145) | more than 11 years ago | (#4601965)

If you can do it at all, use something like Python: custom software is much easier to write in it than in C++, and it has good support for numerical operations. Java, too, is much easier and safer than C++.

If you have to use C++, then wxWindows is a great environment: it works on lots of platforms and has extensive support for platform-independent I/O, threading, and networking.

WxWindows and GCC maybe? (5, Informative)

Dog and Pony (521538) | more than 11 years ago | (#4601976)

http://www.wxwindows.org/ [wxwindows.org] - mature crossplatform C++ library, and not only for GUI, either.

I don't know what you need, but WxWindows and GCC cross-compiling (see mingw32 faq [mingw.org] , for instance) might be what you need?

WxWindows also have good bindings to python and perl etc. for more rapid crossplatform development.

Java? (1, Informative)

Anonymous Coward | more than 11 years ago | (#4601981)

Um Java??

No its not as stupid as it sounds.
A few years back there was a good article on this
in magazine that I used as the base for a system
we developed.

All user interactions as handled by a Java client
(if you prefer Python, Perl, Lisp wahtever) easy to code, easy to run wherever there is a JVM.

All your number crunching, algorithms, (back end stuff) goes into libraries that you call by
JNI. Just make sure you do not make the JNI API
too specific, try to keep to coarse, and the number of calls to it done. That is have high level of abstraction on the JNI API.

Huh? (2)

wandernotlost (444769) | more than 11 years ago | (#4601983)

What tools and strategies can we use to increase our productivity and regain our competitive advantage, without going for Windows only?

All Windows productivity oxymoron jokes aside, how do you go from most of your users being on Solaris and Irix to thinking about going Windows only?

Erg...I just saw the second part of the article, after the ad. That was annoying. Maybe it's time to sign up for a subscription.

Re:Huh? (0)

Anonymous Coward | more than 11 years ago | (#4602053)

AdSubtract [adsubtract.com]

Kills all ads. On a per-site basis. Rocks. :)

Have you looked at SourceForge as a tool (AD) (-1, Offtopic)

Real World Stuff (561780) | more than 11 years ago | (#4601984)

VA Software Unveils SourceForge Project Management Console

SourceForge 3.2 Delivers Development Intelligence

FREMONT, Calif. -- October 29, 2002 -- VA Software Corporation (Nasdaq: LNUX) today unveiled SourceForge[tm] Enterprise Edition 3.2 -- the latest release of its flagship Development Intelligence application, featuring the new SourceForge Project Management Console. The Project Management Console provides real-time visibility into the entire application development lifecycle through an intuitive dashboard, enabling new levels of effectiveness in software development management.

By automating status updates and delivering project metrics through a real-time interface, the SourceForge Project Management Console helps managers proactively identify, track and resolve potential problems before they impact schedules and budgets. The Project Management Console is an integral component of SourceForge Enterprise Edition 3.2.

"The release of SourceForge Enterprise Edition 3.2 and the Project Management Console marks a fundamental shift in the way organizations can view and manage the application development lifecycle," said David Appelbaum, senior vice president of marketing, VA Software. "By centralizing information on development projects and providing real-time metrics and tools for analysis, SourceForge 3.2 delivers Development Intelligence -- the holistic view of code, content, communications and processes that helps organizations align software development with business goals."

SourceForge Enterprise Edition is used by IT and software engineering organizations in a variety of industries including financial services, defense and aerospace, manufacturing, communications and government to drive quality and efficiency in software development. Current VA Software customers include companies and institutions such as Sandia National Laboratories, General Atomics, Lockheed Martin, Pfizer and LEGATO Systems.

Use boost (1)

yugami (102988) | more than 11 years ago | (#4601986)

http://www.boost.org

besides, do you really think it's the IDE that makes your competitors more competitive? I do crossplatform day in day out, its NOT THAT HARD

Re:Use boost (1)

robbo (4388) | more than 11 years ago | (#4602085)

Woah, back up. Writing cross-compatible STL code is hard enough. I've never used boost, but I can only imagine that it would be a nightmare to use across four different compilers.

Primary platform? (4, Insightful)

binaryDigit (557647) | more than 11 years ago | (#4601992)

Why not do what a great many other people do (though I have a feeling that you may be doing this already), and target a specific platform for initial release, and then release on the others afterward? This allows you to focus on the platform that gives you the most bang for the buck, but still keep your scaling advantage. If you already have an established product/development environment, then you should already know enough to keep from doing any of the "big mistakes" when it comes to writing portable code. Plus this allows you to divvie up your engineers into functionality vs porting.

Another thing would be to standardize on say, gcc. since the source is available, you can do whatever tweaks you need to to get around any performance issues (I know, easier said than done). Then standardize on things like configure.

Own make tool? (0)

Anonymous Coward | more than 11 years ago | (#4601999)

Have you thought about writing a simple make like tool that either generates nmake/gnu make/ant makefiles or build commands? It takes hardly any time if you use something like Spirit to handle the parsing.

Presumably you're already using something like boost? I found it sped things up no end once you get used to it.

Without joining any holy wars about language... (4, Interesting)

buysse (5473) | more than 11 years ago | (#4602002)

It sounds like your biggest problem isn't the cross-platform code as much as the Makefiles and the compiler differences.

I would suggest first using gcc on all UN*X platforms, and also trying out something like ant [apache.org] instead of the various forms of make you're dealing with now.

Also, have you considered using a library like Qt [trolltech.com] 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.

Look several topics down. Design Patterns covers (2, Insightful)

dameatrius (182345) | more than 11 years ago | (#4602015)

this topic (if you haven't read it already). The basic idea is to break out all parts that don't work across the different platforms into their own sections of code (classes/interfaces) assuming you aren't doing that already. Then when you do updates (that will hopefully work platform independantly) you can just right those sections once. Pretty obvious but I have seen so many places with this same issue who actually have completely seperate code bases rather then breaking parts out.

Unfortunately if you are already doing this then you are probably screwed unless someone releases .NET CLR's for all those platforms.

So many compilers - so little time. (2, Insightful)

MicklePickle (220905) | more than 11 years ago | (#4602017)

controlling four different compilers (gcc 3.1, Sun Forte, Irix MIPSpro and Visual C++ 7)

Couldn't you just use gcc across all systems? There are also plenty of opensource IDEs around. We use
Eclipse [eclipse.org] along with ClearCase. Very good for cross platform.

ant instead of make? (2, Informative)

mrjive (169376) | more than 11 years ago | (#4602023)

Ant is an excellent alternative to Makefiles. It might not solve all your problems, but you should at least be able to simplify your build process quite a bit.

Apache Ant [apache.org]

switch to FreeBSD (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#4602027)

Lots of people are switching to FreeBSD and loving it. It's a much nicer environment for clueful developers than Windows or linux.

Single compiler _interface_ (2)

Ed Avis (5917) | more than 11 years ago | (#4602032)

Instead of different makefiles for each compiler, why not write wrappers for the various compilers to give them all the same interface? Then at least for compiler invocation you could have the same makefile for all four platforms, just set CC=cc_wrapper which is a shell script (or .cmd script on Windows, or Perl or whatever) which mangles its command-line options into whatever weird syntax this platform's compiler expects.

With more fundamental issues like differences in the code accepted by different compilers, you can use #ifdefs in the code, which is not elegant but probably much better than makefile hacking.

Some suggested switching to gcc on all platforms, but then others said it might produce slower code. Well, you won't know until you benchmark. It's possible (just) that you might decide to compile most of your object files with gcc, to eliminate most of the compiler-specific hackery, and just compile those parts of the program that are speed-critical using the native compiler. This assumes that the object formats used by gcc and the native compiler are compatible, but in principle there's no reason they shouldn't be. (Perhaps not in practice, but give it a try.)

Re:Single compiler _interface_ (0)

Anonymous Coward | more than 11 years ago | (#4602089)

I've faced this problem before.

1) There are good reasons not to go with gcc on all platforms. It is about 50% slower.

2) We used to have one makefile for all flavors of UNIX, and another makefile for Windows. Because we used ClearCase, we didn't worry about having to encode explicit dependency checking on underlying source files in our makefiles, making them _much_ smaller, and allowing us to focus on coding up the 'how to build' part.

3) Cross platform guis are still hard. Client-server is probably the way to go.

Numerics in Fortran, Front-end in Java (2, Interesting)

PseudononymousCoward (592417) | more than 11 years ago | (#4602034)

Check out the latest edition of OilIT. Applications like this are why Fortran is still a very popular language among those who use computers for numerically-intensive work. Fortran9x is so easily portable, its not even funny. Bindings exist for all of the major threading standards (OMP, MPI, etc) and it is FAST. Further, is there any language with a better selection of libraries available for number-crunching? I doubt it. Develop your 'work' code in Fortran, and your front-end in Java. Both highly portable. The interface between the two will be platform specific, but this will only be a small portion of the total project & much easier to maintain than the large #ifdef heavy project you now have. $0.02

Put platform dependant stuff in libraries (1)

Procyon101 (61366) | more than 11 years ago | (#4602041)

What you need to do to work with the multithreading issues, etc with the multiple systems is create your own primitives that you need, instead of using the vendor supplied ones. For instance, MSVC uses CRITICAL_SECTION whereas cc will use a mutex. The behavior of these are significantly different, but similar in function. What you need to do is create a class that acts as a Mutex, and implement this class differently on the different platforms. Then, in the code where rapid development counts, your Mutex can be used with no regard to platform differences. Do this for all platform dependent things suchas interlocked integer functions, thread creation/destruction, network functions, etc. Use the std lib to wrap some differences, such as file access.

It's very simple. (3, Funny)

eddy (18759) | more than 11 years ago | (#4602042)

Just add more people to your team! Double! Tripple! GO WILD WITH NEW RECRUITS!

Sheeesh, some people never learn...

What we use here (0)

Anonymous Coward | more than 11 years ago | (#4602046)

I work on remote sensing GIS software.

Our software compiles and works under Linux (gcc), Windows (VC++ 6) and Solaris (gcc). The code base in the past has also worked on IRIX (???).

We've had good success using Qt for cross platform libs and GUI and jam (http://www.perforce.com/jam/jam.html) for cross platform builds. I do all my development under Linux and very occasionally cross compile on Windows (couple of times a month).

I'd also suggest getting Purify for one of the platforms or HeapAgent (www.microquill.com) for Windows. I've looked at some of the linux based checkers but they are dog slow when matched with Qt. HeapAgent just flies for checking....

Qt is the obvious answer (1)

g8oz (144003) | more than 11 years ago | (#4602050)

Take a hard look at Qt, I think you'll see that its the solution with the least overhead.

They even have a case about a company like yours that had a similar problem. Take a look.

http://www.trolltech.com/products/success/pgs.ht ml

C++ = Object Orientation? (2, Informative)

pVoid (607584) | more than 11 years ago | (#4602056)

Why not isolate threads and files, and IPC into light-weight objects?

Sure you are going to have incompatible concepts across platforms (e.g. Windows doesn't support just unlinking an inode), but I'm sure you can find a happy subset without making too much compromise.

I know Alias|Wavefront uses a very similar concept for their Studio and Maya products. (studio looks and behaves identically on all platforms - so it *is* possible).

Windows Only (1)

GWOSKB (621825) | more than 11 years ago | (#4602057)

Windows Only, perish the thought. Not that Id condone it....but one must assume certain falacies when one assume windows only.......

Start with a strong cross-platform framework (0)

Anonymous Coward | more than 11 years ago | (#4602059)

I've heard good things about the ACE/TAO cross platform library. From what I've heard, it has a learning curve, but it adds a very strong layer of abstraction over top of the operating system services (network, threading, syncronization).

ACE/TAO are open source and will build on a number of platforms with a number of compilers.
Overview:
http://deuce.doc.wustl.edu/doc/RandD/TAO/Overview/ [wustl.edu]

I'd be interested in knowning... (5, Insightful)

AKAImBatman (238306) | more than 11 years ago | (#4602063)

...why you think you can't use Java.For all the bad press Java gets about being "slow", it is mostly old, outdated FUD. Newer virtual machines are often faster than C/C++ applications, especially in the number crunching arena. Intensive graphics are no big issue since Java now has a fullscreen API (page flipping, double buffering, and all that), a very fast implementation of Java3D, and (if you prefer) OpenGL wrappers.

Even if you feel that Java doesn't cut it for everything, apply the 80/20 rule. 80% of your non-performance critical code in Java, and the later 10& in C/C++. This solution would at least *reduce* your multi-platform woes. You might try posting this on JavaGaming [javagaming.org] . The guys over there are wizards at making Java perform with intensive graphics. (No surprise considering that some of the industries greatest performance experts hang out there.) They can also help you find the APIs you need. I'd really take a second look before you toss Java out as an option.

JNI is your friend (5, Insightful)

Tim Macinta (1052) | more than 11 years ago | (#4602071)

Java is not currently an option for the high-performance numerical and immersive graphical aspect of our applications.

Java isn't an all or nothing deal. You could write your app in Java and then convert the parts that really need performance into C and call it via JNI. Then you only have to deal with keeping a much smaller C library portable.

I think... not that it matters (0)

kberg108 (175765) | more than 11 years ago | (#4602082)

that your Java excuses are bull shit propaganda. My company has built an application that has to proccess numerical values at incredible speeds and in real time and we were advised that C++ would be the only solution. Well we decided to use java and have not had any preformance problems what so ever. But in answer to the your general problem. It sounds to me like your lack of initial architecture is what is killing you. You need to rethink the architecture of your app and put code into the appropraite layers of that architecture. Every time I hear about a problem proting to multiple systems or tweaking code because of compilers, it just screams architecture redesign.

Use OpenOffice.org SDK to build on MultiPlatforms (0)

Anonymous Coward | more than 11 years ago | (#4602087)

Hi,

The OpenOffice.org project builds from one source tree on Windows, Linux (ppc and x86), Solaris (Sparc and x86), and has FreeBSD, NetBSD, Irix, MacOSX coming
soon and the codebase in question uses C++, threads, STL, component technology, etc.

Kevin

Red Hat will sell you gcc for all 4 platforms (0)

Anonymous Coward | more than 11 years ago | (#4602093)

The problem you're facing is exactly what Cygnus
Solutions was created to solve. They were bought by Red Hat 3 years ago, but the same people are still there doing the same thing. Go to the Red Hat website and search for "gnupro".

Adaptive Computing Environment (0)

Anonymous Coward | more than 11 years ago | (#4602096)

A virtue in programmers is laziness well applied.
The easiest way to be lazy is to make use of
someone else's work. Best of all is if it's free.

The Adaptive Computing Environment [wustl.edu]
has already done most of the heavy lifting in terms of cross-platform stuff. Free as in beer, free as in liberty.

Easy (0)

Anonymous Coward | more than 11 years ago | (#4602121)

What tools and strategies can we use to increase our productivity and regain our competitive advantage, without going for Windows only?"

Java.

Whomever said Perl earlier is an idiot.

Select another language (1)

SLOGEN (165834) | more than 11 years ago | (#4602122)

If you are not experiencing performance-constraints, why not use another language?

Personally, I would think that if rapid development and market response is very important, you should probably select an interpreted runtime-typed language... which gives you minimum hazzle when changing desgin, arkitecture and most importantly: implementaion.

One language that would spring to mind is python :)

ACE (0)

Anonymous Coward | more than 11 years ago | (#4602126)

It sounds like you could make use of ACE the Adaptive Communication Environment. C++ wrappers for portability and cross platform developement of high-performance distributed real-time multi-threaded concurrent yadayada applications.

Learn how to JAM my friend! make jam; rm make (1)

bm_underscore (612642) | more than 11 years ago | (#4602131)

Why make when you can JAM! Jam will take care of all of this for you. You spend time creating your rulesets for all your different platforms/compilers and all anybody has to do is type jam to build, regardless of what they are on. I use (and have used) Jam for this purpose and currently use it to build .net C# apps and assemblies using MS command line tools. Previously we used it intensively to support C++ on both GCC 2.95 & MSVC 6.0 on Windows, Linux, and Solaris.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...