🔒 Locked

Getting into Linux/Cross Platform Development

Started by essial Oct 13, 2008 at 12:52 PM 16 replies 3.7k views

Original Post

Oct 13, 2008 at 12:52 PM

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!

deadstar

Oct 13, 2008 at 12:59 PM

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!

swiftcoder

Oct 13, 2008 at 1:12 PM

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.

GenuineXP

Oct 13, 2008 at 1:29 PM

I use Boost Build (bjam). It requires that users have it installed and configured on their system, but it's fairly straightforward to setup. Then building is as easy as:

user@linux:~$ bjam

And, of course, it works just as well in Windows and other supported platforms.

You'll have to learn to write Jamfiles though, but that's always the case with any build system (i.e., learning to write those pesky input files).

I've never really used Code::Blocks much, but I've only ever heard good things.

essial

Oct 13, 2008 at 1:47 PM

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?).

essial

Oct 13, 2008 at 2:07 PM

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.

pinacolada

Oct 13, 2008 at 2:39 PM

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

I've used SCons for a few multi-platform projects, it works really well. On a posix platform, it defaults to using gcc, on Windows it defaults to the MSVC tools. The only cross-platform work you need to do is specify different build flags (since the gcc flags look nothing like the MSVC flags).

Edit: Oops, I guess the 'commands' module is Unix-only, so that's not really cross platform. Maybe this code will do the same thing on Windows.

[Edited by - pinacolada on October 13, 2008 3:39:21 PM]

essial

Oct 13, 2008 at 2:41 PM

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!

essial

Oct 13, 2008 at 5:02 PM

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!

SimonForsman

Oct 13, 2008 at 5:49 PM

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.

xZekex

Oct 13, 2008 at 9:57 PM

I would recommend using cmake over scons or auto tools.

The problem with auto tools is that it isn't cross platform unless you want to generate makefiles for each compiler you come across. And doesn't generate project solutions for KDevelop, Visual Studio or XCode. CMake syntax is alot easier and actually readable.

Problems I've seen but correct me if I'm wrong is that you need to learn another language to use it. Python in this case. Its clean. But it doesn't create project files for ide's either.

CMake is cross platform. It generates project files for every ide you can think of and even just makefiles if you prefer. It uses a clean scripting and uses the files CMakeList.txt. Alot easier to use. Though it takes a little time but not much to make them for the libraries you need, though it includes liek over 40 libraries+. And you can request some from CMake's bug site.

The output is very clean, and like scons clean too. But it comes with a complete count while compiling so you know how long until its finished compiling. I'll post it for cmake when I get my system development stuff setup on my machine.

Bregma

Oct 14, 2008 at 8:21 AM

I do multi-platform development (building the same software natively on multiple platforms). I do cross-platform development (building software for multiple platforms hosted on a single platform). There is nothing like the autotools for accomplishing those tasks. Nothing.

The new so-called "replacement" tools like scons or cmake are simply inadequate. They require that the tool be installed by the target user, the do not support cross-platform builds, and if you want to build for a new platfom, you must first port your tool before you can port yor software.

Yes, there is a learning curve for the autotools, as with any advanced tool that accomplishes a complex task. Yes, there's some archaic syntax and sometimes byzantine rules about what must needs be applied when. There are some interesting replacement projects underway that will, when (or if) competed provide the same featureset as the autotools, but so far there are no candidates for replacement.

I would like to point out that setting up a typical autotools project take one command (autoscan followed by editing two files (configure.ac and Makefile.am). I manually create no files and the editing consists of replacing boilerplate.

My recommendation is that you buckle down and learn to how to use the autotools. It's not that difficult, it's actually quite well documented (the red book, the info pages, the manual that comes with the software in PDF form). There are loads and loads and loads of examples available to follow.

swiftcoder

Oct 14, 2008 at 12:36 PM

Quote:
Original post by Bregma
The new so-called "replacement" tools like scons or cmake are simply inadequate. They require that the tool be installed by the target user

Ever tried running autotools on a system without Make installed? Windows, for instance (sans cygwin)?

Quote:
the do not support cross-platform builds

I am sitting here on a Mac, with a mingw and linux cross compiler, and a CMake project that builds all 3 targets simultaneously. Why you could certainly do that with autotools, it wouldn't be any easier.

Quote:
and if you want to build for a new platfom, you must first port your tool before you can port yor software.

Tell that to anyone who spent months porting an autotools-based build system to Mac or Windows. From my experience, autotools is only decently portable between very vanilla *nix environments.

Bregma

Oct 14, 2008 at 1:30 PM

Quote:
Original post by swiftcoder
Quote:
Original post by Bregma
The new so-called "replacement" tools like scons or cmake are simply inadequate. They require that the tool be installed by the target user
Ever tried running autotools on a system without Make installed? Windows, for instance (sans cygwin)?

It's true. You need a shell and a compiler, too. An runtime libraries. And headers. What you don't need is any of the autotools installed.

Quote:
Quote:
and if you want to build for a new platfom, you must first port your tool before you can port yor software.
Tell that to anyone who spent months porting an autotools-based build system to Mac or Windows. From my experience, autotools is only decently portable between very vanilla *nix environments.

I have ported software written using autotools to both Mac OS X and Windows. It goes pretty much like this.

  ./configure  make

I didn't bother converting the project to use a different build system.

Mind you, I was using MingW32 on Windows. The autotools does require a POSIX build environment. It's extremely portable between anything vaguely POSIXlike or Unixlike (ie. it ran fine on my Atari ST and Amiga).

Biggest advantage to using the autotools is that there's an awful lot of software out there that already suses it, so (a) if you run into problems it's already been solved by someone else, and (2) you will probably end up having to understand it in order to use third-party software anyway.

MindFlayer

Oct 22, 2008 at 4:30 AM

Have you ever considered using Java for your projects? I find C++ incredibly burdensome for hobbyist game programmers and always cry a little when I see it used when it's not really needed. There are some really good opensource IDEs for Java such as Eclipse available for any *nix, 3D engines such as JMonkeyEngine and so on. And it's cross-platform of course. :)

I'm just trying to say that there are easier alternatives to this horrible autotools/library/C++ mess.

larvyde

Oct 29, 2008 at 9:58 AM

I am using autotools myself, and give it a thumbs-up. Here's a tutorial:
Autotut

Quote:
Original post by essial
To get a fully working "compile", you have to have around 5 files you have to manually create

really? I count only 2 or 3 --configure.ac and Makefile.am and maybe a header to include in config.h-- everything else is generated with (in linux) 'autoreconf -vifs'

HuntsMan

Oct 29, 2008 at 10:03 AM

Quote:
Original post by Bregma
I do multi-platform development (building the same software natively on multiple platforms). I do cross-platform development (building software for multiple platforms hosted on a single platform). There is nothing like the autotools for accomplishing those tasks. Nothing.

Not true, the KDE project moved from autotools to CMake sucessfully, and it compiles on *NIX, Windows, and Mac OS X, without problems (other than non-portable code problems, X11 dependencies, etc).

Bregma

Oct 29, 2008 at 10:33 AM

Quote:
Original post by HuntsMan
Quote:
Original post by Bregma
I do multi-platform development (building the same software natively on multiple platforms). I do cross-platform development (building software for multiple platforms hosted on a single platform). There is nothing like the autotools for accomplishing those tasks. Nothing.

Not true, the KDE project moved from autotools to CMake sucessfully, and it compiles on *NIX, Windows, and Mac OS X, without problems (other than non-portable code problems, X11 dependencies, etc).

Correction: KDE compiles natively on various Posix (where CMake has been ported) and WIN32 platforms without problems. It does not build at all on platforms where CMakes has not been explicitly ported already. It does not cross-compile at all. You will not see KDE running on your ARM-based handheld any time soon, because it just takes too long (weeks) to build under an emulator, and first you have to bootstrap the entire OS and port CMake. I'd like to see THAT done on a gameboy.

KDE chose to use CMake because they don't need to port to new compilers or operating systems. Fair enough, You can also limit yourself to those platforms. After all, they all run on consoles and handhelds, right?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.