Compiling an open source project in Visual Studio for dummies?

May 11, 2012 10:28 AM

I need to compile an open-source software package, originally intended for a POSIX machine, in Visual Studio. I am comfortable with the ./configure > make > make install cycle, having done it many times, but I have never used VS in my life. Can someone explain to me like I am six, what I would do to begin doing this in VS? I can't make a makefile, because configure is a bash script. I realize I could use MinGW or Cygwin, but I've been asked to avoid that if possible. I already have VS (C++ version) and also SDK installed on a Win 7 box. Let's assume for this question that using a pre-built binary is not an option.
posted by sandettie light vessel automatic to computers & internet (21 answers total)

Typically when I have done this, I have started by getting a makefile made by configure (using cygwin, sorry) and then crafted either a custom script or a visual studio makefile from this. After a while you get used to figuring out what options you'll need to specify to configure, and what sort of tweaks you'll need to make to the resulting nmake makefile. If you've never used MSVC before this is probably going to be a giant pain in the ass, frankly.

How many source files are we talking here? I admit that on some simpler cross compile platforms I make a makefile for unix/os and just a flat script for windows, like, compile these source files, link these source files, done. If there are hundreds of files and they're not all compiled the same way that can be a pain in the ass.
posted by RustyBrooks at 10:40 AM on May 11, 2012

It's a couple hundred files, altogether, between .c and .h files.
posted by sandettie light vessel automatic at 11:02 AM on May 11, 2012

I know in previous shops we had a way to use cmake to create a .vcxproj file for Visual Studio. But I don't recall if we used a standard makefile as the input.
posted by JoeZydeco at 11:09 AM on May 11, 2012

What open source package? Making a package compile on Windows is a lot harder than just writing some makefiles for VS. Some POSIX like functions will take different arguments, not have the same options, or might not even exist. And that's assuming the developers stuck with a strict POSIX API, which is doubtful.

If this package happens to work on a variety of Unix/Unix-like OSes -- FreeBSD, Mac OS X, Linux, Solaris, etc -- then they should have a port directory where they've already abstracted out or re-implemented some known problem functions. Writing a port for Win32/64 should start there.
posted by sbutler at 11:26 AM on May 11, 2012

One way is to run configure && make, then simply snag the resulting config.h, and duplicate all the compiler flags and arguments you see in make's output. You can get a list of source files from looking at the automake input files, or just add everything in the tarball.

Typically all that configure does is generate config.h from config.h.in, and find the necessary include-path and library-path flags for the compiler. Config.h.in is commented— you can generate your own by hand. And the include and library path settings should be easy enough to add iteratively: try to compile with VS, see what header or symbol is missing, add flags, repeat. More of a pain than autoconf, sure, but not too bad.
posted by hattifattener at 11:27 AM on May 11, 2012 [1 favorite]

What package is it? It's possibly someone has already ported in a Win32 fork someplace.
posted by bottlebrushtree at 11:30 AM on May 11, 2012

The package is openldap. I am reconciled to it being a massive PITA; so far hattifattener's route seems to be the most promising.
posted by sandettie light vessel automatic at 11:41 AM on May 11, 2012

Not sure if this is what you're looking for but MSBuild might be a more familiar environment than the Visual Studio GUI.
posted by XMLicious at 11:46 AM on May 11, 2012

Do you really need to do it in the VS GUI? Why not use the Microsoft command line compiler (I'm assuming they still bundle it in) and make (either gnu or cygwin or whatever microsoft gives you)? Still a pain to translate all the flags over, etc., but maybe somewhat less pain.
posted by DarkForest at 12:22 PM on May 11, 2012

Yeah, I may end up doing that, DarkForest. No one cares if I use the GUI; it's just that the binary that resulted from compiling with Cygwin has issues, and they want to use MS tools to compile.

I'll add that I was not involved in the Cygwin attempt.
posted by sandettie light vessel automatic at 12:30 PM on May 11, 2012

I was assuming that the source code already had an option to interface to win32 written into it, so that it could run on windows. If not, then it will probably be a big job porting it.
posted by DarkForest at 1:03 PM on May 11, 2012

I would create a new project and then import all of the .c and .h files. Then I would set about making it build. VS will know where the SDK libs are.

There will be crt issues... you will have to rename some functions to start with an underscore. You will probably also find it uses some that have been deprecated for security reasons.

If (when) you run into linking errors, I'd be happy to help you try to sort through them via mefimail, but I can't promise anything. You will get useful help here as well. Mostly it will be familiarizing yourself with all the compiler and linker options in the project settings.
posted by jeffamaphone at 1:13 PM on May 11, 2012 [1 favorite]

Thank you, everybody. This is more clues than I had earlier.
posted by sandettie light vessel automatic at 2:35 PM on May 11, 2012

A quick google show a few sites offering openldap for windows, and not all of them are companies. Maybe a quick email asking them how they did it?
posted by benito.strauss at 6:17 PM on May 11, 2012

This smells like a deathmarch to me. Are you absolutely sure you need openldap? Is there truly no way to persuade Active Directory to do what you want instead?
posted by flabdablet at 8:31 PM on May 11, 2012

Importing the project in VS should do most of the work for you. This package doesn't require nasm like openssh iirc. Speaking of which, there's a guide to compiling curl for windows on the site (pdf) that might offer a few helpful hints, even if it's for a different package. (You do have the option to use openldap instead of msldap, though I never bothered to investigate it.)
posted by IronLizard at 2:57 AM on May 12, 2012

The build system isn't the issue. The issue is what APIs it uses. If it is really meant for a POSIX system and it hasn't actually been ported to Win32, then no amount of adding files to a project and fussing about with config.h will make it work. You will need to actually port the code, which means editing and adapting it to use the Win32 APIs. This is no small feat.
posted by Rhomboid at 5:58 AM on May 12, 2012

In fact it's so not-small that it was worth creating a fairly large project (Cygwin) solely to avoid having to do it.

Have you been specifically asked to avoid linking your project against cygwin.dll, or simply to avoid using the usual GNU-based Cygwin development toolset?
posted by flabdablet at 7:10 AM on May 12, 2012

flabadblet, the bins built with Cygwin ended up being unlinkable for some reason to other objects in the project. Again, I am coming cold into this, so that's all I know yet.
posted by sandettie light vessel automatic at 8:31 AM on May 12, 2012

If you run dumpbin /exports on the Cygwin binaries, does it look as expected? You may just need to tweak the Cygwin project a little bit to make it work.
posted by jeffamaphone at 8:52 AM on May 12, 2012

It would certainly be worth your while finding out whether the problem was actually caused by the cygwin.dll POSIX compatibility layer specifically, or by e.g. trying to link gcc-compiled object files to VS-compiiled ones.
posted by flabdablet at 10:47 AM on May 12, 2012 [1 favorite]