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? :-)
Related
I'd like to create a Makefile for a moderately sized C++ project (~110 .cpp and .h files) that was created in Xcode. I don't own a mac, so I can't just go into xcode and export a Makefile.
From my understanding of using Makefiles for simpler projects, I could go through and create a target in my Makefile for each .cpp file, including its prerequisites... but that would require manually looking through each file and sorting out what its dependencies are.
It's my understanding that autoconf is a good tool for this sort of problem, but I haven't been able to figure out how to set it up and I'm not even sure that it's the right tool for the job. So before I go even further down this rabbit hole --
What is the best way to create a Makefile for an existing project without one?
It is rather subjective as to the best tool. Perhaps look at SCONS or gradle to compare for your particular needs.
I think Pbxbuild may help you.
Pbxbuild (not to be confused with the OS X tool of the same name) is used to take Xcode project files and build the code. It does this by creating GNUmakefiles, and using Make to build those.
Any build system (generator) will require some learning on your part. I would suggest using CMake, if you do not mind that CMake will be required wherever anybody tries to build your source. Otherwise I would suggest using the Autoconf/Automake/Libtool combo.
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.
What is MakeFile in Eclipse? From the documentation:
A makefile is a text file that is referenced by the make command that
describes the building of targets, and contains information such as
source-level dependencies and build-order dependencies. The CDT can
generate a makefile for you, such projects are called Managed Make
projects. Some projects, known as Standard Make projects, allow you to
define your own makefile.
But the explanation does not help me understand what a MakeFile is. I am moving from VisualStudio/C# to Eclipse/C++. Is MakeFile analogous to Visual Studio's Metadata? When do I need to write a MakeFile, and why do I need it besides the C++ code?
[EDIT]
I used to develop on Windows with VS and C#. And now trying Eclipse/C++ on a Mac. I have never build anyone on Linux. So the answer I have read so far does not help explain anything at all.
A makefile in the simplest terms is a file that builds a program. These are normally used from the command line. If you have ever built something on linux you may have run ./configure ; make ; make install. You are using a makefile there.
More info...
https://en.wikipedia.org/wiki/Make_(software)
In simple terms: Make helps you create cross-platform configuration settings in one file, and it will work on surprisingly many platforms, including Windows or Mac OS-es.
Mentioning Windows, you should have Make installed on the computer you're installing on (on Windows, Cygwin and MinGW include Make). It's required only if the user will actually build the code from the source.
But of course, you should include Make code for each different platform (e.g. one for Unix-like, one for Windows, etc.)
i have source code of vc++ project. Now I am using linux.
i know how compile a single file .cpp not a whole project. So how to compile a VC project using g++ ?
A slight advantage of Makefiles would be possible integration with autotools (cough - It might prove handy to get the starting point for feature macros).[2]
There is a tool as part of winemaker that is EXCEEDINGLY helpful with fixing up a source tree that was assuming case insensitive names to work on a case-sensitive filesystem. (_it was intended mainly in order to build against winelib but that is not required)
If you want to keep using windows API's for some parts of the code, you can consider compiling with winelib (and use winegcc, producing WIN32 executables; I'm not sure whether this is what you want)
[2]: SCons is a very nice tool though
First step would be to generate Makefile out of vcproj file.
There are (obviously) some tools for that:
http://www.codeproject.com/KB/cross-platform/sln2mak.aspx
There is no easy way to do it. As others have suggested you can figure out how the build process works for this project (maybe by reading the build output in VS) and recreate that using your favorite linux build tool (scons, cmake, autotools etc.). The alternative is to use a converter tool. Aside from the below mentioned sln2mak, there is also winemaker. The docs for winemaker have a lot of old info like most linux tools docs but it can convert a .sln to a makefile. I am not sure about newer vs .sln files.
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.