x64 platform for Google Flags on Windows

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Download gflags 1.3
2. Open the provided solution file
3. Cannot build a 64-bit version

What is the expected output? What do you see instead?
There should be a 64-bit (x64) platform option for building Google Flags on 
Windows. Currently, only Win32 option is available

What version of the product are you using? On what operating system?
gflags 1.3
Windows 7 64-bit
Visual Studio 2010

Please provide any additional information below.

Original issue reported on code.google.com by dattan...@gmail.com on 9 Jul 2010 at 3:57

[GoogleCodeExporter]

I know very little about windows development, and nothing about win64 
development.  (I also don't have access to a win64 machine).  If you can submit 
a patch to get things working for you, I'm happy to consider it.

Original comment by csilv...@gmail.com on 9 Jul 2010 at 3:45

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I don't know autotools. Would you consider switching to Cmake? I can provide a 
Cmake file that works with all platform.

Original comment by dattan...@gmail.com on 9 Jul 2010 at 4:14

[GoogleCodeExporter]

I don't know autotools. Would you consider switching to Cmake? I can provide a 
Cmake file that works with all platform.

Original comment by dattan...@gmail.com on 9 Jul 2010 at 4:14

[GoogleCodeExporter]

No, sorry, I'm going to stay with autotools -- I'd rather not have to add cmake 
into the mix.

For windows, of course, we don't use autotools, but just a sln and vcproj 
files.  So maybe you can just edit those?

But I don't know what changes you need to get things to compile under win64; 
that is, what's not working now.

Original comment by csilv...@gmail.com on 9 Jul 2010 at 5:55

[GoogleCodeExporter]

Ok. I will look at the solution file for 64-bit and see what I need to do. I 
will post an update.

Original comment by dattan...@gmail.com on 9 Jul 2010 at 8:10

[GoogleCodeExporter]

Putting this CMakeLists.txt at the source folder of gflags. Then run cmake to 
create your Visual Studio solution (may it be 32-bit or 64-bit).

This will create a solution file that has two targets:
* gflags
* gflags_unittest

They both build correctly (having similar warnings to the existing 32-bit 
solution file).

I run gflags_unittest with the ${gflags_src}/src/windows as my start up 
directory. The output is also attached. Could you please take a look to see 
what I can improve on?

Original comment by dattan...@gmail.com on 10 Jul 2010 at 5:52

Attachments:

• CMakeLists.txt
• gflags_unittest.output

[GoogleCodeExporter]

Does this mean that people who want to build on windows would need to have 
cmake installed?  Or is cmake capable of producing .sln/.vcproj files?  I don't 
know anything about cmake.

I don't want to add an extra dependency on a particular build system, and I 
don't want to have to support three build environments (autotools, msvc, and 
cmake).  It would be ok to just have to deal with autotools and cmake, though, 
if it didn't change the requirements for users.

It might be easier just to change the existing windows environment to work with 
win64.  What errors do you get when you try to build with the existing .sln?

Original comment by csilv...@gmail.com on 12 Jul 2010 at 5:38

[GoogleCodeExporter]

Unfortunately, cmake requires the user to have cmake. Since you mentioned that 
you would like to continue using autotools, introducing cmake only for windows 
might not be the best choice. The problem is that cmake is a (better) 
replacement for autotools. It does require a separate download but gives the 
user more options. 

I respect your choice so it is your call. Let me see if I can make a second 
platform target for 64-bit from the existing 32-bit.

Regarding build error, I get the same error as in gflags_unittest.output if I 
were to build for 32-bit.

Original comment by dattan...@gmail.com on 12 Jul 2010 at 7:41

[GoogleCodeExporter]

Yeah, I'm willing to accept cmake is a better build platform, but until it's 
standard everywhere, I don't want to ask folks to have to use it.

} Regarding build error, I get the same error as in gflags_unittest.output if I 
were to build for 32-bit.

Sorry, I'm not sure I understand this.  Looking at gflags_unittest.output, it 
looksl ike the test is passing, to me.  What problems are there?

} Let me see if I can make a second platform target for 64-bit from the 
existing 32-bit.

That would be great!

Original comment by csilv...@gmail.com on 12 Jul 2010 at 10:56

[GoogleCodeExporter]

The build error refers to the warnings that I get when compiling with Visual 
Studio. I wanted to ask you to take a look and see if the outputs are correct.

Since the outputs are correct, I will try to make the 64-bit port of the 
platform target in Visual Studio.

Original comment by dattan...@gmail.com on 12 Jul 2010 at 11:45

[GoogleCodeExporter]

cmake is definitively the best choice . 
CMake is a family of open source tools designed to build, test and package 
software. CMake is used to control the software compilation process using 
simple platform and compiler independent configuration files. CMake generates 
native makefiles and workspaces that can be used in the compiler environment of 
your choice. 

Original comment by david.al...@gmail.com on 14 Jul 2010 at 4:02

[GoogleCodeExporter]

@allouche: I think csilvers agree that CMake is a better build platform. I 
agree as well. Yet, no matter how hard we push for it, there are other choices 
out there and we should respect their choice (even when the choice is not good).

@csilvers: your statement is a catch 22. Unless a library as finely written as 
gflags start adopting CMake, how could folks start switching more agressively? 
If folks don't switch, how would it be "standard everywhere"? If it is not 
standard everywhere, then gflags won't switch :-). 

Anyways, rhetorical aside. It turns out that it is very easy to create a x64 
platform target. Simply choose to create a new target and copy the Win32 one 
already available.

I am including here the extra files which when copied to an unzip gflags source 
folder, will add a google-gflags-vs2010.sln solution file that have both win32 
and x64 platform targets. I have tested that gflags-unittest all runs with PASS.

I would vote to have the CMakeLists.txt file included in the patch as well, 
however.

Original comment by dattan...@gmail.com on 14 Jul 2010 at 4:56

Attachments:

• gflags-vs2010.zip

[GoogleCodeExporter]

} It turns out that it is very easy to create a x64 platform target.
} Simply choose to create a new target and copy the Win32 one already available.

Could you expand on this a little?  Are these steps that you take inside MSVC?  
If these instructions are simple enough, I'd be happier just adding them to the 
README (or a new README_windows.txt file), than having to include more files in 
the distribution.

Original comment by csilv...@gmail.com on 15 Jul 2010 at 12:40

[GoogleCodeExporter]

The steps to do this inside of MSVC is:

1- Open the provided solution file
2- To create x64 target, click on the Win32 target (on the right of
Debug/Release)
3- Choose Configuration Manager
4- In Active Solution Platforms, choose New...
5- In "Type of select the new platform", choose x64. In "Copy settings
from:" choose Win32.
6- Ok
7- Close

You can now build gflags for 64-bit platforms

With warm regards,

Dat Chu
Research Assistant, Computational Biomedicine Lab (www.cbl.uh.edu)
Dept. of Computer Science, University of Houston, Houston, TX 77204-3010
Tel: (832) 772-7135
Email: dtchu@central.uh.edu

Original comment by dattan...@gmail.com on 15 Jul 2010 at 4:13

[GoogleCodeExporter]

OK, I'll make this part of my next release, in a news README_windows.txt file.

Original comment by csilv...@gmail.com on 16 Jul 2010 at 10:23

• Changed state: Started

[GoogleCodeExporter]

Thank you. Happy Google Flagging.

Original comment by dattan...@gmail.com on 16 Jul 2010 at 10:29

[GoogleCodeExporter]

There's a README_windows.txt file in gflags 1.4, just released.  Hopefully that 
helps with this issue.

Original comment by csilv...@gmail.com on 14 Oct 2010 at 1:22

• Changed state: Fixed