Here's how I do it, works pretty well:
- the build is described through cmake, target platforms are either
Windows, Linux, OSX or via cross-compiling iOS, Android, emscripten and
- for cross-compiling-platforms, cmake toolchain files are used (see here
for the emscripten toolchain
- for Windows and OSX (and iOS) target platforms, VisualStudio and Xcode
projects are generated and most development happens in those IDEs because a
debugger is available (so usually I program and debug the native Windows or
OSX executable, 99% of bugs happen also on the native build and are easier
to debug there)
- for cross-compiling platforms, I usually just compile on the command line
with make or ninja (on Windows I use ninja exclusively since I didn't get
make to run outside of mingw)
- for writing emscripten, pnacl or Android-specific code I usually fall
back to VIM (or any other simple text editor), but the platform-specific
code is very little compared to the whole code base, also since debugging
on these platforms is usually not possible I use good-ole printf-debugging
there, but it's rare that there are bugs in the platform-specific code
- with cmake, you can just do 'cmake --build .' to start a command-line
build for any platform or cross-compiling scenario, this starts the right
build system for the cmake-generator that is used (VisualStudio: msbuild,
Xcode: xcodebuild, make or ninja for cross-compiling)
- I prefer OSX or Linux for emscripten work, since these have proper
command line shells, and don't have some of the Windows shell limitations
(like max number of characters in a command line, which I was running into
with emscripten builds). It may be that PowerShell doesn't have these
restrictions, alternatives may also be the new Linux subsystem in Win10, or
a VM (I use Vagrant to easily setup and launch VirtualBox VMs on Windows).
I noticed that clang is several times slower on Windows, vs OSX or Linux,
most likely caused by slower IO (e.g. building in a Linux VM in a local VM
filesystem (not shared from Windows), clang or gcc builds are also fast)
Generally I find that the greatest advantage of using an IDE is the
integrated debugger, but you don't get that in emscripten anyway, that's
basically the main reason why I haven't used the VS integration.
I also wrote a little python wrapper around cmake to better juggle the many
different build systems, but this specific solution might be too limiting
for existing projects: http://floooh.github.io/fips/
Still, thinking about a few small wrapper scripts to make the many
different build configs more manageable might be a good idea.
Hope this helps,
Am Freitag, 14. Oktober 2016 21:06:22 UTC+2 schrieb David Sleeper:
> We have a remote Windows application publishing product with many
> different native clients: Windows, Linux, Mac, iOS, Android. Most of these
> compile from the same C++ code base. We want to use Emscripten to create an
> HTML5 client. I've been tasked with implementing the build environment.
> First question: What OS produces the best outcome?
> Most of our development is done using Visual Studio 2008 so Windows is the
> most desired OS for developing the Emscripten client port to HTML5. We are
> not interested in upgrading to Visual Studio 2010 just to get the
> Emscripten vs-tools functionality. If/when we do upgrade it will be to the
> latest version of Visual Studio. Mac OSx and Linux are possible options but
> not everyone is as comfortable developing with them so there will need to
> be compelling reasons to use one over Windows.
> Second question: Assuming Windows is a valid answer to the first question,
> what is the best build solution?
> I'm having trouble finding any information on where to start with Visual
> Studio builds that don't use Visual Studio 2010 and the vs-tools. It looks
> like cmake is the most likely choice, but I'm not familiar enough with
> 'make' build systems to know for sure.
> Any advise is greatly appreciated and if there is a post or blog that I
> missed a link would be great.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.