While working on my project, I realized from the start that I cannot have a shell script to simply do a few GCC commands, as every linux system is different -- plus I wanted my code to be buildable on non-linux (FreeBSD, Mac, Windows, etc) machines as well. This led me to whats called "AutoTools". The programs include: aclocal - http://www.gnu.org/software/automake/manual/html_node/Invoking-aclocal.html autoconf - http://www.gnu.org/software/autoconf/ automake - http://www.gnu.org/software/automake/ Not only is the overall build setup process a huge burden (in my opinion of course) on the developer, but each tool in and of itself is very poorly documented (also, in my opinion). All of the information is ~technically~ there, but it is in a very non-user-friendly format. There are a lot of "tutorial" sites out there showing you how to create a basic shell application, but almost no information on how to do typical things such as including 3rd party libraries and such. Most of the time, it is hit and miss googling that eventually gets me to the answers I seek. To get a fully working "compile", you have to have around 5 files you have to manually create (not counting simi-required files such as NEWS TODO etc), and about 20 other files that get generated by the command line tools you have to run. Now there is also scons and cmake, but both seem to be a little "iffy" on support (whereas autotools has been around forever), and using those tools seem to have their own little problems. Now I know that there is a little overhead when it comes to writing applications that can compile on multiple systems but honestly -- they've had 20 years to make things easier, and it doesn't seem to ever change. Considering the amazing improvements that Gnome, X11-xorg, and driver support have recieved over the years, I find it slightly depressing that if you want to write a C/C++ app, you still have to drag yourself through the mud to get anything working. I should note that I have finally figured it out enough to get my program to compile, and still have the thoughts I had above. I'm also aware of the mono project and mono-develop, but do not see .net as a direct replacement to C/C++ as .net has a completely different purpose in programming than lower level languages. I'm also aware of kdevelop, but kdevelop feels extremely bloated and heavy, and doesn't feel very unified. If anyone has any comments, or knows of a great resource for figuring out autotools -- or some viable, well supported/used alternative, I'm all ears!

Code::Blocks - I never went back.

I had KDevelop for a long time, and slowly got used to it's problems and reaped the benefits. It's prefect for any Qt development, but the laborious setup process for wxWidgets was the finally blow for me.

Give Code::Blocks a try, it requires almost nil setup to get a C++ project up and compiling. I'm gonna wait for the KDE4 effort of KDevelop to mature, and I'll have another play.

EDIT: Just a footnote, Code::Blocks has the ability to import a Visual Studio 2003+ project too. Bonus!

Quote:Original post by essial
If anyone has any comments, or knows of a great resource for figuring out autotools -- or some viable, well supported/used alternative, I'm all ears!

CMake and SCons - both modern replacements for make and autotools. I have used both to build software on Windows/Linux/Mac without changes. CMake I find easier to use, but SCons is considerably more powerful.

Quote:Original post by swiftcoder

Quote:Original post by essial
If anyone has any comments, or knows of a great resource for figuring out autotools -- or some viable, well supported/used alternative, I'm all ears!

CMake and SCons - both modern replacements for make and autotools. I have used both to build software on Windows/Linux/Mac without changes. CMake I find easier to use, but SCons is considerably more powerful.

Which of these systems would you recommend? Right now I'm using autotools, but would love to move from them if I can. My requirements is to be able to add `sdl-config --cflags` and `sdl-config --libs` to the compile options, as well as -lSDL_image and such libraries. I will also need to be able to have the option to "install" natively, including any resources/media.

If you can tell me that one of those can do the above with less pain than autotools, I'll be all over it. I like scons a little more than CMake (I ~think~ anyway, scons is the python based system right?).

Oh, and its not important but I should mention that I'm a Gtk+ guy, I dislike wxWidgets -- both because of their licensing snafus, and because of the fact that Gtk's design paradigm just about forces good program layouts (in my opinion of course). I hate statically placed UI controls as they disallow true theme customization.

Quote:Original post by pinacolada

Quote:Original post by essial

Which of these systems would you recommend? Right now I'm using autotools, but would love to move from them if I can. My requirements is to be able to add `sdl-config --cflags` and `sdl-config --libs` to the compile options, as well as -lSDL_image and such libraries. I will also need to be able to have the option to "install" natively, including any resources/media.

If you can tell me that one of those can do the above with less pain than autotools, I'll be all over it. I like scons a little more than CMake (I ~think~ anyway, scons is the python based system right?).

I'm a huge fan of Scons. Yes, it's Python based. Essentially, you write a Python script which calls SCons functions to tell it what you want to build (and how to build it). From this, SCons makes a dependency tree, then looks at what files you have on disk, and figures out what it needs to rebuild.

It's quite smart about it too; for example, it remembers what build flags were used to create every build artifact. So, if you change the build flags, it knows to rebuild everything. (Make doesn't do that, I'm not sure if CMake does)

Since you have access to everything Python, adding flags from sdl-config is pretty easy. Your SConstruct file would look something like this:

import commandsenv = Environment()env.Append(CPPFLAGS = commands.getoutput("sdl-config --cflags"))env.Append(LINKFLAGS = commands.getoutput("sdl-config --libs"))

You are a god among men pinacolada. Thanks!

Ok, I got scons compiling with the following:

import commandsimport globenv = Environment()# determine compiler and linker flags for SDLenv.ParseConfig('sdl-config --cflags')env.ParseConfig('sdl-config --libs')# obtain the source filesSOURCES = glob.glob('src/*.cpp')env.Append(LIBS = ['SDL_mixer', 'SDL_image'])# output the binaryenv.Program(target = 'spengine', source = SOURCES)

But I still cannot figure out how to allow installation. I see the documentation on an "install" build, but that example specified literal paths (in this case, "/usr/bin"), instead of where the OS actually expects it to be.

Is "make install" now not preferred? I have no problems building an RPM, DEB, and .EXE installer for my app if that is the way things are going now.

Thanks again!

Quote:Original post by essial
Ok, I got scons compiling with the following:

import commandsimport globenv = Environment()# determine compiler and linker flags for SDLenv.ParseConfig('sdl-config --cflags')env.ParseConfig('sdl-config --libs')# obtain the source filesSOURCES = glob.glob('src/*.cpp')env.Append(LIBS = ['SDL_mixer', 'SDL_image'])# output the binaryenv.Program(target = 'spengine', source = SOURCES)

But I still cannot figure out how to allow installation. I see the documentation on an "install" build, but that example specified literal paths (in this case, "/usr/bin"), instead of where the OS actually expects it to be.

Is "make install" now not preferred? I have no problems building an RPM, DEB, and .EXE installer for my app if that is the way things are going now.

Thanks again!

If its an opensource project you can release it as source only during the early stages of its development, once the software is in a state where non developers could find it interesting you should build .rpm and .deb installers. (For proprietary software you shouldn't release source ofcourse)

As for where you're supposed to place the binaries and data you can refer to the FHS

Its also a good idea imo to allow users to install the application entierly in their home folder using a path like: ~/yourappname/ and then position the files just like you would for a windows application.