I''m not quite sure what you''re asking. Most projects I''ve seen have either a VC++ project file, a GCC makefile (or other) or nothing at all.

Generally, the project should be organised in such a way that there aren''t many steps a user has to go through to compile your program.

Mostly projects are organised with the c++ files in a ''src'' folder and the headers in an ''include'' folder. Installation/compilation is mainly adding the include folder to the include path and compiling the cpp files.

Platform dependant things are often separated out with #defines and compiler directives to ensure the program will compile correctl in that environment. For example, VC++ and many windows-based compilers will #define _WIN32

A simple:
#ifdef _WIN32
#include <windows.h>
#endif

will ensure windows headers are included. It''s a very good idea to completely partition off any platform dependent code into separate files/directories. So imagine you were writing a timer - Windows has GetTickCount() which isn''t around on linux. You''d then create a CTimer_Win32 / CTimer_Linux (based on a CTimer interface) class that is totally dependent on that OS. Entry points are also the same, windows can be a WinMain() or main() for DOS/Linux. By carefully crafting the defines, you can ensure that the correct files are included and the correct implementations are created.

#ifdef _WIN32  #include "Timer_Win32.h"#else  #include "Timer_Linux.h"#endif.... in your code// base class....CTimer *timer;#ifdef _WIN32 timer = new CTimer_Win32();#else timer = new CTimer_Linux();#endif // get time, which will call the relevant code... timer->getTime();

This is a very trivial example, so don''t shoot me down. It just helped explain what I meant, I think.

Most things i''ve seen have offer packages for linux and compiled binaries for windows. This can be done since most windows systems are fairly homogenous. For linux, there are are many different flavors of linux and not everybody comes standard with the required libraries and such, so you can''t assume dynamically linked libs are there when they might not be.

For linux/UNIX systems, usually source distributions of software come in .zip or .tar.gz "tarballs". They usually include a configure script which creates a makefile, then the makefile of course. Ideally, a linux user should just be able to unzip and type

./configure
make
make install

and that oughta do it. If you want to distribute software in a *nix environemnt, you should really learn about how to set those up. Anything that doesn''t come with a configure/make script doesn''t get my time.

For windows, i usually find projects to come with VC or Dev-C++ project files. They should just unzip and compile as well.

I''ve never used KDevelop and i''m no GNU MAKE expert, so i''m not sure what it has to offer. I think what most people do (quite frankly) is rip a configure script from some other project, change a few things, and use that. Sorta like we all do with our own code. Very rarely is it all from scratch.

What ./configure tries to do is find out if you meet all the requirements to build the project. It checks if you have the right compiler, right libs, files in the right place, permissions, all that. If everything checks out, it automatically creates a makefile for you when it runs. Then you run the makefile which is (more or less) guaranteed to work since it was created with configure and not made by hand.

If configure fails, it (hopefully) will tell you why. like "Oops! You don''t have SDL installed. Go install it and try again."

Of course, in linux, you could (and should) bind up your compiled project in an .rpm (RedHat) or .deb (Debian) package for easy pre-compiled installation, besides the source package. Just don''t ask me how :-)