Developing on Linux(First attempt)

Started by
10 comments, last by gimp 19 years, 11 months ago
I''ve been coding in MSVC for years, I migrated from 6 to .NET about 2 years ago(to a beta from TechEd) so I''m not afraid of trying stuff out. I had a look a KDevelop last night on a Knoppix Live CD. I tried out what apears to be a hello world template. Everything looked fine so far though the interface is a little sparcer than VS(I like sparce anyway). Without reading any doco I tried to build\compile the project and debug step though each line of code. Each time I tried to compile this little 1 line program it took ages to compile calling gcc then g++(?) and a few other things... I cound never seen to work out how to step though my code, that said I didn''t even bother with the doco. Does anyone have an tips for converting a large VS application to compiling on Linux. I should have little problems with all the platform specific stuff. Is there any way to convert solution \ vcproj files in to something useful in a linux development suite?
Chris Brodie
Advertisement
i recommend Clanlib for some very nifty cross platform game related uses. As far as converting microsoft generated projects to a linux development environment, you have to understand that linux hackers who create these tools are more interested in making their tools better in a feature and reliability sense than they are to write converters for us microsoft-reliant people.

I have written a couple of cross-platform programs and what I found was the biggest problem was not anything to do with transporting to Linux, but having good code. When writing something in msvc it is very possible to write bad code (not to standard) and that gets you into trouble when crossing over to linux. Actually, even going back to msvc proved to be troublesome because of some weird things that msvc does different than mingw and gcc. So, I guess the only thing I would recommend (which it is a bit too late for now) is to make sure that you are writing code that complies with the standards.
-Greg
The only thing I worry about in my code is the for loop''s. I rely on local scoping of (for int i=0...) where i has a scope only within the for loop. I often have a few of these in a row, something that''ll possibly trip a redefinition compile time error in GCC if it doesn''t support this(I''m sure it would).

I don''t use any funky recursive templates or partial specialisation etc. Apart from that where will my VS coding practices let me down?

My main concern is porting all that knowledge about the dozen libraries that my game uses in to new libraries in linux, porting all those settings to ignore warnings in tri.c and blah.cpp(mostly imported code) dependencies. It takes a while to set it all up. I guess I''ll have to do it the slow way...
Chris Brodie
quote:Original post by gimp
The only thing I worry about in my code is the for loop''s. I rely on local scoping of (for int i=0...) where i has a scope only within the for loop. I often have a few of these in a row, something that''ll possibly trip a redefinition compile time error in GCC if it doesn''t support this(I''m sure it would).


Not to worry, that''s the way of the C++ standard, and it''s also the way g++ has (afaik) always done it.
for(int i=0; i<10; i++)  printf("i=%i",i);printf("Loop finished, i=%i",i); 


I haven''t used C++ for months now (total switch to C#), but if I recall correctly, the above code does -not- compile with G++.

Note that GCC and G++ differ - G++ passes some extra C++ related arguments to GCC, if I recall correctly here, too.
I use for loop scope variables on a fairly regular basis in g++. It works fine. MSVC++ actually gives me problems with them though because it attempts to define the variables at the next level up in the scoping. As a result, if you have two for loops that declare "int i", MSVC++ complains at me. I admit I was just using a friends computer to do a cross-compile of my project and know very little about MSVC++. Perhaps I could have fixed it by changing options or using a newer version (I think he had Visual Studio 6?). In general, I've found g++ (especially with the '-ansi' flag) to be a much more standards compliant compilier than MSVC++.

gcc is a c compilier, and g++ is a c++ compilier. There probably wouldn't be any reason to use both of them, although kdevelop may call the compiler you use multiple times. I wouldn't imagine it would do this for a hello world program, but in the project I'm using it for it compiles all the classes individually and then compiles/links them all together. I don't know for sure, though, that project is my first attempt at kdevelop. You could try compiling your program from the console to see if the slow speed is from kdevelop or the actual compilier.

One thing that may slow kdevelop down is that it handles all of the automake/autoconf stuff for you. It shouldn't be reconfiguring the project everytime you try to build or execute it, though.

[edit]Removed a not very helpful comment about debugging.[/edit]

[edited by - Mr Grinch on May 26, 2004 3:09:53 AM]
I had a look a KDevelop last night on a Knoppix Live CD.

It''s been my experience that Live CD''s are somewhat slow when starting/ending applications. That may explain the prolonged build time.
Take a look at CMake. It lets you maintain a very simple makefile from which you generate either a unix-style makefile or project files for your IDE of choice. It saves you the pain of maintaining and synchronizing the Windows project files and the unix makefile.

--
AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.
[Project site] [Blog] [RSS] [Browse the source] [IRC channel]
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
Some of the Linux IDEs (I haven''t used them all - and I haven''t for a while) have a tendency to run autoconf on each build you do.

Autoconf is EVIL, unnecessary and a right pain in the arse.

Whatever IDE you use, ensure that it does not use autoconf.

Just make a Makefile for Linux - if you really need to work on other Unix-like platforms, make makefiles for them too.

Mark

This topic is closed to new replies.

Advertisement