Yes, we’ve done some of the libraries in that stack already:
(*really* nice job on that page & script by the way, it’s the clearest instructions for that stuff that I’ve ever seen :D )
Off that page, we already have
win-iconv
zlib
libffi
freetype
libxml2
libpng
glib
pixman
openssl
And yes, we’ve done these using MSVC ( vc10, vc11 * release, debug * static, dynamic *x86, x64 )
The VC12 preview release is coming at the //build conference this month, and we’ll add that into our matrix when that comes out. (it may be late july-ish, I think
we’re going to make a change to split up the .lib/.dll files into smaller, fine grained satellite packages)
I was looking at your scripts to see if we could merge efforts there too. (one of the things that lead me here was looking at your page)
You can see most of the ‘native’ nuget packages we’ve built in the gallery :
https://nuget.org/profiles/coapp/ (well, a few of those are .NET pkgs, but look for the ones marked ‘native’ )
Right now, we shallow fork projects here (https://github.com/coapp-packages/
), and add our build files (usually found right now in the /COPKG/ folder in the project)
The script file that iterates over the variations is the .buildinfo (example:
https://github.com/coapp-packages/freeglut/blob/master/COPKG/.buildinfo
)
And you can see one of our simplified .vcxproj files (https://github.com/coapp-packages/freeglut/blob/master/COPKG/freeglut.vcxproj
) -- this still loads in VC10 and VC11 too.
Nice part about these builds, is that they’re all pretty atomic – dependencies are brought in using the packages and so anyone can generally rebuild an individual
package.
Garrett
From: Arnavion [mailto:arnavion gmail com]
Sent: Wednesday, June 12, 2013 12:03 PM
To: Garrett Serack
Cc: gtk-devel-list
Subject: Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
You mentioned that you have done work to provide builds of common open-source libraries. Can you provide more information on this?
- Do you mean that these builds are done using MSVC?
- Does this include any libraries that GTK depends on?
On Wed, Jun 12, 2013 at 10:19 AM, GarrettSerack <garretts microsoft com> wrote:
Howdy Folks,
(apologies for resurrecting this older thread, but it felt the most
appropriate way to continue this conversation...)
(and, apologies for the long-ish email, it's a big topic :D )
My name is Garrett Serack - I work as a Senior Developer in at Microsoft in
the Open Source Technology Center -- my role here is to help get open source
software running better on Windows--my management specifically cares about
things on Windows *Server* (ie, PHP, Apache, MySQL, Node.js etc) , but so
very many things are needed for some of those that it's really not much of a
distinction.
Aaaanyway.
In addition to the (W)AMP stack I have an extremely strong interest to see
quality builds of the whole GTK+ stack (and as many apps as will run) make
their way onto Windows.
This spring, we added support for Native C/C++ packages to NuGet (a library
package manager that up till now was .NET only) -- this makes it pretty darn
easy to produce, share and consume C/C++ libraries in VC10, VC11 (and
beyond). The packaging of the libraries is extremely flexible in that it can
handle all the different variations of a given library across any number of
'pivots' -- Compiler (VC6,7,8,9,10,11,etc) , Linkage (static, dynamic, ltcg,
sxs), Configuration (Release, Debug), C Runtime Library Linkage
(static,dynamic), Platform (x86, x64, arm) ... and pretty much any other
varation that you want to provide variations on.
The support for VC is handled by generating a msbuild .targets file that
gets imported into the consuming project which intelligently sets up all the
settings needed to actually compile and link against the package.
Working with some members of our community, we also started making builds
available of common open-source libraries -- and then we started to hit GTK+
and friends, and as I dug deeper into the process of building all of them,
it became clear that the better approach would be to work with everybody who
is trying to build the libraries and try to make one consistent approach to
building and packaging the libraries up on Windows.
We've been working to make better basic project (.vcxproj) templates than
the less-than-stellar ones that ship with Visual Studio. We've distiled down
the necessary stuff to make it far simpler to make project files for
building all of these libraries, and remove all the cruft and confusing
stuff that's come from a decade and a half of Visual Studio development.
I've also done a ton of work to improve automating over a given set of
projects to produce all the different variations of a given build, for
multiple compilers, so that when we package up a given library, we give as
many variations as possible.
My goal here is to make these libraries easy to build and consume for as
many varations (compilers, platforms, etc) as possible. I know that this
can be done with a single set of VCXProj files (which wne properly iterated
over, can generate all combinations of the libraries for all the VC
compilers).
I'd like to work along with anyone who's interested.
Garrett Serack
garretts microsoft com
twitter: @fearthecowboy
Things I've been considering
============================
- Generate some files for CMake as well and include them in the library,
which would make it possible to consume libraries in CMake-based builds.
This wouldn't be too difficult, since in the generator I've already got all
the information I need to produce the files, it's just likely to be at least
a couple weeks worth of work. I should actually ping Bill Hoffman on that...
- At some point in the future, I'd also like to add toolset support for GCC
so that MSBuild could compile with it as well (I think adding in the right
stuff to the project at http://daffodil.codeplex.com/ would be the best for
that)
- Currently, the tools for building the packages rely heavily on the
MSBuild infrastructure, so it's not currently possible to run them on
non-Windows platforms, but it may be possible to move towards using Mono's
xbuild (or, just treat the vcxproj .targets files as xml and just 'do what
we know we need to' instead of using the flimsy wrappers in msbuild's object
model.)
More Information
===================
Announcement:
http://coapp.org/news/2013-04-26-Announcing-CoApp-Tools-For-NuGet.html
Packging Native Libraries Tutorial:
http://coapp.org/tutorials/building-a-package.html
https://www.youtube.com/watch?v=l4MAkR13JPA
Channel 9 interview:
http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-16-Garrett-Serak-Inside-NuGet-for-C
--
View this message in context:
http://gtk.10911.n7.nabble.com/Windows-32-64bit-downloads-and-or-bundles-for-2-x-and-3-x-tp80686p81291.html
Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com.
|
