We have a not very complicated but big (i.e. lots of files) Visual Studio C++ Win32 Console written in C++0x standard in VS2010.
It does not use any non standard code or anything (Hopefully!).
I now wanna port it to Linux.
Which way is the quickest way to do it?
autoconf?
old-fashioned make file?
any other solution?
I would use regular make but keep it simple with default rules as much as possible. Add in dependencies as you go along.
EDIT: As in interim step, build it with mingw so that you can avoid the whole API porting issue until you have a working build in your new build mechanism.
If your console app calls win32 API functions then you have a choice between modifying all the source where it is used or writing a module that implements those functions.
In prior porting efforts of this type I tried it both ways and the latter was easier. I ended up writing only about 18 to 20 shim functions.
It was successful enough that I ended up writing an OS abstraction layer that was used on many projects that simply let me compile on Windows native, cygwin, Linux, VxWorks, etc. with trivial changes to one or two files.
(p.s. Any interest in an open source version of a C++ based OS abstraction layer? I was thinking of releasing an unencumbered version of it to the world if there's sufficient interest. It's mostly useful where BOOST is too heavy -- i.e. embedded projects.)
Most probably you don't need autoconf (and I suggest you don't touch it, unless you love pain), because you are not trying to be portable to a dozen of Unix flavours.
Roll your Makefiles manually. It shouldn't be too difficult if you have a set of shared rules and have minimal Makefiles that just specify source files and compile options.
Use GCC 4.5 as it supports more C++0x features.
You can export a make file from Visual Studio.
Update: Actually you can't anymore, unless you have VC6 lying around
STAY AWAY FROM AUTO* and configure. These are horrible IMHO.
If you can somehow get a VS 8 or 9 vcproj/sln, you can use this. I have not used it, so I can't give any advice.
If you're up to manual conversion, I would suggest something like CMake, as it's pretty easy to get ready fast enough, even for large projects.
If the project has a simple layout, you could have success using Qt 4's qmake like this:
qmake -project
It will output a qmake .pro file, which can be converted into a makefile on many platforms (using qmake). This should work okay, but not perfectly. Alternatively, you can install the Qt plugin for VS, and let it generate the pro file from an existing VS project. It will make your build system depend on Qt4's qmake, which is probably not what you want.
There are of course other things like cmake, but they will all require manual intervention.
The fastest way to do it?
g++ *.cpp -o myapp
Seriously, depending on your needs, even generating a makefile might be overkill. If you're just interested in a quick and dirty "let's see if we can get a working program on Linux", just throw your code files at g++ and see what happens.
Related
I'm a C++ beginner and I'm starting to develop my first cross-platform C++ project. I need to use platform-specific calls (Win32 and POSIX) so I need to compile frequently both in Windows and Linux.
Whit single-platform projects I'm using, until now, KDevelop in Linux and Visual Studio 2012 in Windows.
How can I use two different IDEs in two different Operating Systems with the same project?
Should I use a single, cross-platform, IDE?
Should I learn CMake (or similar) and configure it to work with both IDEs?
Could/Should I host my code in the web and sync automatically with offline projects?
Alternatives?
Thanks in advance to everyone.
EDIT:
Just for clarification, the project will be a simple server for a scholastic protocol. There will be a client asking for upload/retrieve some files to/from the server.
With scholastic I mean that, for example, I have to use pthreads/win32 threads instead of an higher level C++ threads library.
Maybe - really depends on what you feel most comfortable with. As the project is non-graphical, all the IDE gives you is editing of files and compilation. So you can build the project on one machine with the IDE there, and then move the sources to another machine for compiling there.
I personally would just have two makefiles, one for Linux and one for Widnows. Makes life fairly simple [you could have a "outer" makefile that picks the right one based on some clever method].
Yes, you should find a version control system that works for both Windows and Linux (git, mercurial, subversion, bazaar and several others). That way, not only do you have a central repository [you can use either of your machines as "server" for any of these], but it also allows you to keep track of your changes. Definitely worthwile doing!
There are hundreds of different alternatives. But the simpler you keep it, and the less complicated your tools are, the more time you get to spend on actually programming your project, rather than, for example, figure out why CMake isn't building the way you want it to.
Also, make sure that you separate out all your system-specific code to one file per architecture. That way, it's easy to port to another architecture later, and it makes MOST of your code compile on both systems.
Typically, it's easy to adjust the IDE-specific project/build files to added/moved/deleted source files. Therefore, using a cross-platform IDE isn't that important.
You can do that, I think that CMake can also create project files for some IDEs that can then be used to build the project.
Ahem, if you want to host it online or not is your choice. What you should definitely do is to use some kind of version control. A bug-tracking system is also helpful. If you want to open-source the code anyway, using one of the existing hosting facilities is a clear yes.
Not really.
One comment though: You will have much more trouble making the C++ code portable. Building on top of a toolkit like Qt is a tremendous help. If you want to stay closer to standard C++, at least consider using Boost for stuff like threads, smart pointers, filesystem access. Good luck!
My recent experience suggest to take a look at Qt. The IDE (QtCreator) it's very good, and available on all major platforms.
I've used for a fairly simple project, that uses fairly complex components, like OpenCV and ZBar. I develop on Linux, copy the source to Windows, and recompile.
I had some trouble to setup OpenCV on both platforms, so I can't say it's super easy, but it's working. Since you already know KDevelop, you should already know Qt.
I also put much value in recent trend that see Qt5 as the platform for Ubuntu on smartphones. I really hope to see this developing.
HTH
How can I use two different IDEs in two different Operating Systems with the same project?
Should I use a single, cross-platform, IDE?
No. I think this is a case of asking the wrong question. To make a cross-platform project, what matters is your build scripts and the system-neutral nature of your code. Sometimes it might help to have project files for your preferred IDE, but maintaining multiple project files for multiple IDEs will only make things more difficult and complex for you. Instead, you should focus on finding a build system that minimizes the amount of time you spend on project maintenance.
For that, CMake and PreMake seem to be two of the best tools to make that happen.
There are dozens of alternatives (like SCons, Cook, kbuild, Jam and Boost Jam, and many others), but since CMake and PreMake both generate project files and build scripts, they might be the best solutions.
Your mileage will vary.
Could/Should I host my code in the web and sync automatically with offline projects?
You should have robust source control that works everywhere you do. Git and Mercurial seem to work best if you use some kind of "cloud" hosting like Github or BitBucket, but they by no means require it. Depending on your work environment and team size, you may prefer Subversion or PerForce or something else, but that's up to you and your team.
it will help, you will quite likely need to debug on many platforms... Qt Creator, Netbeans and Eclipse come to mind.
Yes. cmake, or qmake for Qt maybe
Not technical question. Just use version control! github and gitorious are easy choices for open source project though.
Qt is a no-brainer choice for cross-platform C++ GUI app, and also decent choice for network app with no GUI.
I have a project containing C/C++ files. I'd like to build it without using make. What are my options? I'd like cross platform solutions if possible.
I've used SCons and it is very good.
SCons is an Open Source software construction tool—that is, a next-generation build tool. Think of SCons as an improved, cross-platform substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache. In short, SCons is an easier, more reliable and faster way to build software.
I've also looked at cmake but have not seriously used it.
Well, you're always going to need some way to invoke the compiler. If it's a trivial project, you can usually just stick all the .C filenames on the command line of the compiler and get some kind of output.
Or you can use a batch file / shell script instead of a makefile, but it would be less 'cross-platform' than a makefile and much less useful.
You should probably explain your motivations more clearly.
Since you're going to use Boost anyways (right?) Boost.Jam might be an option.
I already used WAF in some of my projects and it worked out quite well.
If you are familiar with python...
A common alternative is to write python scripts to compile your code.
How are you editing you code? Can that system also build it for you?
Visual Studio, Eclipse, XCode, KDevelop? :-)
We have a handful of developers working on a non-commercial (read: just for fun)
cross-platform C++ project. We've already identified all the cross-platform libraries we'll need. However, some of our developers prefer to use Microsoft Visual C++ 2008, others prefer to code in Emacs on GNU/Linux. We're wondering if it is possible for all of us to work more or less simultaneously out of both environments, from the same code repository. Ultimately we want the project to compile cleanly on both platforms from the start.
Any of our developers are happily willing to switch over to the other environment if this is not possible. We all use both Linux and Windows on a regular basis and enjoy both, so this isn't a question of trying to educate one set devs about the virtues of the other platform. This is about each of us being able to develop in the environment we enjoy most yet still collaborate on a fun project.
Any suggestions or experiences to share?
Use CMake to manage your build files.
This will let you setup a single repository, with one set of text files in it. Each dev can then run the appropriate cmake scripts to build the correct build environment for their system (Visual Studio 2008/2005/GNU C++ build scripts/etc).
There are many advantages here:
Each dev can use their own build environment
Dependencies can be handled very cleanly, including platform specific deps.
Builds can be out of source, which helps prevent accidentally committing inappropriate files
Easy migration to new dev. environments (ie: when VS 2010 is released, some devs can migrate there just by rebuilding their build folder)
I've done it and seen it done without too many problems.
You'll want to try an isolate the code that is different for the different platforms. Also, you'll want to think about your directory structure. Something like
project/src <- .cc and .h files
project/src/linux|win <- code that is specific to one platform or the other
project/linux <- make files and other project related stuff
project/win <- .sln and .csproj files
Basically you just want to be really clear what is specific to each system and what is common.
Also, unit tests are going to be really important since there may be minor difference and you want to make it easy for the windows guys to run some tests to make sure the linux code works as expected and the other way around.
as mentioned in previous posts, Qt is a very easy method to do real simultaneous multi-platform development - independent of your IDE and with many different compilers (even for Symbian, ARM, Windows CE/Mobile...).
In my last and current company I work in mixed Linux- and Windows-developer teams, who work together using Subversion and Qt (which has a very easy and powerful build-system "QMake", which hides all the different platform/compiler specific build environments - you just have to write one build file for all platforms - so easy!).
And: Qt contains nearly everything you need:
simple string handling, with easy translation support and easy string conversion (utf8, utf16, asci...)
simple classes for file i/o, images, networking etc.
comfortable gui classes
graphical designer for the gui layout/design
graphical translation tool to create dynamic translations for your apps (you can run one binary with different selectable languages - even cyrillic, asian fonts...)
integrated testing framework (unit tests)
So Qt is a full featured and very reliable environment - I use it for 10 years.
And: Qt integrates seamlessly into IDEs like VC++, Eclipse or provides its own IDE "QtCreator".
see: http://www.trolltech.com + http://doc.trolltech.com
Best Regards,
Chris
I had such experience working in Acronis. We had the same codebase used to build binaries (fully packaged installers, actually) targetting Win32/64, Linux, and OS X (and a bunch of other more exotic platforms, such as EFI), with everyone working in their IDE of choice. The trick here is to avoid compiler- and IDE-specific solutions, and make your project fully buildable from clean cross-platform make files. Note that you can perfectly well use any make system together with VC++, so it isn't a problem (we used Watcom make for historical reasons, but I wouldn't recommend it).
One other trick you can do is add a make script that automatically produces project files from the input lists in your makefiles, for all IDEs you use (e.g. VS and Eclipse CDT). That way, every developer generates that stuff for himself, and then opens those projects in IDE to edit/build/debug, but the source repository only has makefiles in it.
Ensuring that code is compilable for everyone can be a problem, mostly because VC++ is generally more lax in applying the rules than g++ (for example, it will let you bind an rvalue to a non-const reference, albeit with a warning). If you compile with treat warnings as errors, and highest warning levels (with perhaps a few hand-picked warnings disabled), you will mostly avoid this. Having contiguous rolling build set up is another way to catch those early. One other approach we've used in Acronis is to have the Windows build environment have Cygwin-based cross-compilation tools in it, so any Windows dev could do a build targeting Linux (with the same g++ version and all) from his box, and see if that fails, to verify that his changes will compile in g++.
I personally use cmake/mingw32/Qt4 for all my C++ needs.
QtCreator is a crossplatform IDE which is somewhat optimized for qt4 programming.
We're working on a cross-platform project as well. We're using Emacs to code, SCons to build and Visual Studio 2008 to debug. It's my 1st time using Emacs + SCons and I must say that It's very very nifty once you figure out how does the SConstruct and SConscripts work.
I'm late to this question, and there are a lot of good answers here, but I haven't seen anyone enumerate all the issues I've run into (most of my work in C++ is and has been cross-platform), so:
Cross-platform compilation. Everyone has covered this quite well. CMake, and SCons are useful among others.
Platform differences. These aren't actually limited to Linux v Windows. Different versions of Windows have plenty of subtle issues. If you ever want to jump from Linux to OS X you'll find the same. So do processor architecture differences: 32 v 64 bit doesn't usually matter - until it does and things break on you very badly. This is something C++ programmers face more than in most other languages, whose implementations are working hard to hide this sort of thing from programmers.
Test everything. Alan mentions unit tests but let me emphasize them. The real problem with cross-platform programming is not code that won't compile: it's code that compiles just fine and does the wrong thing in subtle cases. Unit tests matter here much more than they do when you are working on a single platform.
Use portable libraries whenever possible. Getting this right is full of subtle gotchas. It's better to take advantage of someone else's work than to roll your own. Qt is useful here, as are NSPR and APR (the latter two are C, but wrappers exist if you don't want to mess with them directly.) These are the libraries that explicitly target platform abstraction as a goal, but most other libraries you use should be checked for this. Be reasonably wary of cool libraries that don't have a track record of portability. I'm not saying don't use them: just test first. Doing this right saves you enormous effort on testing.
Pavel mentions continual integration. This may not matter if there are only a handful of you. But I've found that the number of platforms you get when you consider all of the OS, OS variant, and processor differences means that without some form of continuous build-test cycle you will always be missing some edge case. If your project gets bigger than a handful of people consider doing this.
Version control. The most obvious issue is handling newlines and filename case-sensitivity but there are others. Most of the well-known open source VCSes do this right by now, but it's notable that it usually takes them several years to find all their bugs related to portability. As an example Mercurial, which has had portability as one of its selling points, has a series of fixes spanning three or four releases dealing with Windows filenames in uncommon situations. Make sure you can check out what the others check in early on.
Scripts. Use Perl/Python/Ruby (or something like them) for your scripting. Trying to keep Linux shell and Windows batch scripts in sync is painfully tedious.
Despite all of the above: overall cross-platform is quite doable, and there's no real reason to avoid it. My experience is that the problems tend to crop up sporadically, but when they do they take more than there fair share of time. If you've been programming a while though you won't find that unusual.
The issue is not really editing the C++ source files, but the build process itself. VS doesn't use the same Makefile architecture as Linux development typically does. A radical suggestion, but both groups could actually use the same C++ IDE and build process - see Code::Blocks for more info.
This is possible (I do that to earn my daily money :-) ).
But you have to keep in mind the differences in the OS supplied libraries which could be very annoying.
Two good options to get around that are BOOST and QT.
Both supply you with platform independent functions of useful stuff that isn't handled by the C lib and the STL.
I've done this in two ways:
Each platform has its own build system. Whenever someone changes something (adding a source file), they either adapt the other platform too, or they mail a notification and someone more familiar with the other platform adapts it accordingly.
Use CMake.
I can't say I really liked CMake, but a cross-platform tool certainly has its advantages.
Generally, using different compilers to compile your code from the very first few lines is always a good idea, as it helps improving code quality.
Another vote for cmake.
One thing to watch out for, filenames are cased but not case sensitive on Windows. They are case sensitive on most unix filesystems.
This is generally a problem with #include
eg. given a file FooBar.h
#include "foobar.h" // works on Windows, fails on Linux.
I do agree with everyone here that has suggested cmake for cross platform development in C++. It is an excellent tool.
Another thing I would suggest is to use eclipse CDT as development environment. It works in any place where you can run Java an gcc and that unifies your development environment.
I think that was Alan Jackson who gave emphasis to the unit test. For doing so yo would need some cross platform unit test libraries. I read this post time ago regarding C++ unit test frameworks. It is a bit outdated but thoughtful. The one missing that also works in both platforms is googletest.
Finally if you want to run those test automatically in both platforms cmake has another tool called ctest that is very good for doing so.
Check out premake... It is pretty similar to CMake but written using lua.
I have used this on a number of development projects and find it easy to learn and integrate into existing company and project structures.
Give it a try!
http://industriousone.com/premake
I decided to leave my windows install behind and am now running Debian as my default OS. I have always coded in Windows and specifically with Visual Studio. I am currently trying to get used to compiling my code under linux.
Although I still have a lot of documentation to read, and don't expect you guys to make it too easy for me, it'd still be nice to get some pointers on where to start. I have some specific questions, but feel free to suggest/recommend anything else regarding the subject.
What are recommended guides on creating a make file, how do I compile from this makefile (do I call g++ myself, do I use 'make'?)
Looking at other linux software, they almost always seem to have a 'configure' file. What exactly does it do? Does it only check if the required libraries are installed or does it more than just checking requirements?
How do I link libraries, and how does this relate to my makefile or g++ parameters? In windows I would compile the library, include some header files, tell my linker what additional lib file to link, and copy a dll file. How exactly does this process work in linux?
Recommendations for code editors? I am currently using nano and I've heard of vim and emacs, but don't know what the benefits of them are over eachother. Are there any others, and why would I consider them over any of the previous three? Note: I am not looking for an IDE.
Any help, links to guides & documentation (preferably those that are aimed at beginners) are very much appreciated!
What are recommended guides on creating a make file, how do I compile from this makefile (do I call g++ myself, do I use 'make'?)
You build from the makefile by invoking "make". And inside your makefile, you compile and link using g++ and ld.
Looking at other linux software, they almost always seem to have a 'configure' file. What exactly does it do? Does it only check if the required libraries are installed or does it more than just checking requirements?
It's a script usually used to set up various things based on the environment being used for building. Sometimes it's just a basic shell script, other times it invokes tools like Autoconf to discover what is available when building. The "configure" script is usually also a place for the user to specify various optional things to be built or excluded, like support for experimental features.
How do I link libraries, and how does this relate to my makefile or g++ parameters? In windows I would compile the library, include some header files, tell my linker what additional lib file to link, and copy a dll file. How exactly does this process work in linux?
ld is the GNU linker. You can invoke it separately (which is what most makefiles will end up doing), or you can have g++ delegate to it. The options you pass to g++ and ld determine where to look for included headers, libraries to link, and how to output the result.
Recommendations for code editors? I am currently using nano and I've heard of vim and emacs, but don't know what the benefits of them are over eachother. Are there any others, and why would I consider them over any of the previous three? Note: I am not looking for an IDE.
Vim and Emacs are very flexible editors that support a whole bunch of different usages. Use whatever feels best to you, though I'd suggest you might want a few minimal things like syntax highlighting.
Just a note to go with MandyK's answers.
Creating make files by hand is usually a very unportable way of building across linux distro's/unix variants. There are many build systems for auto generating make files, building without make files. GNU Autotools, Cmake, Scons, jam, etc.
Also to go more in depth about configure.
Checks available compilers, libraries, system architecture.
Makes sure your system matches the appropriate compatible package list.
Lets you specify command line arguments to specialize your build, install path, option packages etc.
Configure then generates an appropriate Makefile specific to your system.
What are recommended guides on
creating a make file, how do I compile
from this makefile (do I call g++
myself, do I use 'make'?)
I learned how to write makefiles by reading the GNU Make manual.
Looking at other linux software, they
almost always seem to have a
'configure' file. What exactly does it
do? Does it only check if the required
libraries are installed or does it
more than just checking requirements?
The configure file is usually associated with autotools. As the name of the script suggests, it allows you to configure the software. From the perspective of the developer this mostly means setting macros, which determine variables, which libraries are available, and such. It also tests for the availability of libraries. In the end the script generates a GNU Makefile, which you can then use to actually build and install the software.
The GNU build system is only one of many. I don't particularly like the GNU build system as it tends to be slower than others, and generates an ugly Makefile. Some of the more popular ones are CMake, Jam (Boost Jam might be of interest for C++) and waf. Some build systems simply generate Makefiles, while others provide a completely new build system. For simple projects writing a Makefile by hand would be easy, but "dependency checking" (for libraries, etc) would also have to be done manually.
Edit: Brian Gianforcaro also pointed this out.
Your question is a bit too general, but here is what I would recomment:
Editor: vim and emacs are popular. What matters the most, as with most tools, is to master one. I like using vim because vi (its descendant) is available everywhere, but that may not be very relevant, specially if you stay on Linux. Any programming editor is fine.
configure: unless you do big projects, don't bother with it. It is a nightmare to use and debug. It only makes sense if you intend to distribute your project - in that case, read the autobook: http://sources.redhat.com/autobook/. As other said, there are alternatives (cmake, scons, etc...). I am quite familiar with both scons and autotools, but I still use make for small (couple of files) projects.
Concerning shared library: it is almost as windows, except that you link against the shared library directly - there is no .lib vs .dll distinction in Linux. For example. for one library foo with a function foo:
int foo(void)
{
return 1;
}
You would build it as follows:
gcc -fPIC -c foo.c -o foo.o
gcc -shared foo.o -o libfoo.so
A main (of course in real life you put the API in a header file):
int foo(void);
int main(void)
{
foo();
return 0;
}
And then, you link it as:
gcc -c main.c -o main.o
gcc main.o -o main -L. -lfoo
The -L. is here to say that you want the linker to look in the current directory (contrary to windows, this is never done by default in Linux), the -lfoo says to link against the library foo.
So to get you started I will first point you to this guide for makefiles, it also covers some linking stuff too.
It's just a little something my university Computer Science prof gave us I found it to be very clear and concise, very helpful.
And as for an IDE, I use eclipse usually because it handles the makefile as well. Not to mention compile and standard output are right at your fingertips in the program.
It was mainly intended for Java developing, but there is a C/C++ plugin too!
Recommendations for code editors? I am
currently using nano and I've heard of
vim and emacs, but don't know what the
benefits of them are over eachother.
Are there any others, and why would I
consider them over any of the previous
three? Note: I am not looking for an
IDE.
Vi and Emacs are the two quintessential Unix editors; if you are set on using a text editor rather than an IDE, one of them or their derivatives (vim, xemacs, etc) is the way to go. Both support syntax highlighting and all sorts of features, either by default or via extensions. The best part about these editors is the extensibility they offer; emacs via a variety of lisp, and vim via its own scripting language.
I personally use Emacs, so I can't say much about Vim, but you should be able to find lots of information about both online. Emacs has several good tutorials and references, including this one.
EDIT [Dec 2014]: There seems to be a trend of cross-platform and highly extendable editors recently. This could be a good choice if you'd like something less than an IDE, but more graphical than vi/emacs and native-feeling across multiple platforms. I recommend looking at Sublime or Atom; both of these work across Windows/Linux/Mac and have great communities of plugins and themes.
I recommend the book The Art of Unix Programming by ESR. It covers choice of editor, programming language, etc. It also gives a good sense for the mindset behind programming on Unix or Linux.
For editors, you probably want either Vim or Emacs. They are both different and which one is better is more about personal taste than anything else. I use Vim. It is great for quickly moving around the code and making changes. I didn't like Emacs as much but many people do. Emacs is extremely extensible and can be used for everything from a news reader to an ide. Try both and see what you like.
Recommendations for code editors? I am currently using nano and I've heard of vim and emacs, but don't know what the benefits of them are over eachother. Are there any others, and why would I consider them over any of the previous three? Note: I am not looking for an IDE.
If you're using Linux with a window manager (KDE, Gnome, etc.) you could also consider using the standard text editor for your window manager. The main benefit it would have over vim/emacs/nano is that it would seem more familiar to one coming from a Windows environment - an editor written to run on the window manager has a menu bar, file open/save dialogs, undo/redo, and plenty of other neat features that console editors probably can't match. (Though emacs and vim are pretty sophisticated these days, so who knows ;-P)
On KDE (which is what I use) I can recommend KWrite, which is a well-featured but fairly basic text editor with syntax highlighting; or Kate, which is a fancier text editor with some extra features: session management, a builtin terminal panel, automatic invocation of make, and several plugins including a C/C++ symbol viewer. I usually use Kate for my C++ work when I don't want to bother with setting up a full IDE project. (FYI the IDE for KDE is KDevelop)
the space between invoking g++ directly and using an autotools build chain is pretty narrow. Get good at autotools, which is really the closest thing to a 'project' available in the Linux/Open Source world.
For someone coming from Visual Studio, all this commandline stuff might seem arcane and messy.
Before you turn into a bash shell/vim/emacs junkie, try a few GUI based tools first so you have some transition time...
QT 4.5 with its QT Creator mini-IDE. This is the best framework, lightyears ahead of the competition.
Eclipse (C++) - From my experience with this on Windows, I find it's astounding ( This is probably the best Java application ever written )
KDevelop
Anjuta
If you use Delphi, Lazarus/FreePascal is a good alternative.
I'm sure the longhairs will scoff and claim that vim or emacs gives them the best and fastest development environment, but different strokes for different folks. Someone accustomed to an IDE will take some time to switch or may not wish to switch at all.
For all their editing prowess, creating GUI apps is certainly not a job for 80x25 tools.
It takes years to become an expert with the command line side of things, its more of a transformation of worldview than anything else.
As a side note amongst the proper answers here.. In case you wanna hit the ground running as a Windows guy, I'd suggest the fresh new Qt SDK. It will feel like home :-)
I advise using SCons in place of Make, it does the same job but it's easier to use and handle out of the box how to make dynamic libraries, dependencies, etc. Here it is a real life example for a simple prog
env = Environment()
env.Append(CCFLAGS='-Wall')
env.Append(CPPPATH = ['./include/'])
env.MergeFlags('-ljpeg')
env.ParseConfig("sdl-config --cflags --libs")
env.ParseConfig("curl-config --cflags --libs")
env.ParseConfig("pkg-config cairo --cflags --libs")
env.Program('rovio-pilot', Glob('./src/*.cpp'))
As a text editor, I'm happy with JEdit for coding, but it's a matter of taste.
I have a fairly complex Xcode project and I want to add Qt to it. I know that I can create a new project using qmake -spec macx-xcode project.pro but I don't want to have to hand configure my old project over the auto generated Qt project. Is there another option?
[edited in a more general question below]
It seems like it would be easier to simply use qmake as my build system. Hence, adding my old project build process to the .pro file and use that to generate a new .xcodeproj? I would only do this if I could comprehensively configure the .pro file so that I don't have to hand configure the .xcodeproj - is this doable? I really don't want to have to mess around with hand configuring the .xcodeproj each time I run qmake.
Essentially, is qmake (or a meta-build in general) a valid substitute for a normal build system, such that I don't need to tweak the resulting build system generated by qmake?
Are there better resources besides the manual and tutorial provided by Trolltech? I'm concerned that wikipedia says that qmake is primarily for internal use and not well documented.
One of the main points of using Qt is the portability of the Gui. It only makes sense to extend this feature to your build process by using qmake and allowing users/developers generate whichever build system they want to use (make, visualstudio, xcode).
No, qmake is not well documented and more poignantly there are not manifold examples like there are for make. But, it is similar to make and should be intuitive. Why not absorb the overhead to learn it and pass the benefit on to your users/developers?
Build an empty xcode project with qmake and incorporate the compiler settings to your existing project from the generated Makefile. Of course, you will have to set up your existing project to run qmake as a pre-build step if you are using Qt-specific extensions.
What do you think is the easiest method for integrating established projects with Qt?
That depends on the nature of your work. I wish I could have given a more specific answer here but I really can't. Also, are you using Qt professional? In that case, you can get support (at least that's how it was, during 3.3 when I last worked on it for anything production-quality). If all you care about Qt is the graphics part, I'd say don't bother changing your build system, rather see to it that you get the code to compile and link and run just fine. But, if you are going to use signals and slots and what not -- think about moving over.
Would you recommend I do the xcodeproj merge I asked about and which you answered, or should I start from scratch with qmake like I edited a question about?
Again, look at the size of your project. Assuming a fairly complex project, I'd hazard a guess that you have about 2/3 man-days worth of effort to rewrite the build system? Is this project a serious one, something that will be maintained over a period of time? Is this cross-platform? Will you be using Qt throughout?
If there is an overbearing reason to feel that Qt is the way forward I'd suggest that you start using their build system.
It's really, really, really nice to have a single IDE and debugger that works on all the platforms you are writing for, but I have found that it's also pretty nice to just use the native tools.
Once you put in the time to learn each build system, it's pretty easy to maintain the projects to a very precise degree.