Re: [Mingw-w64-public] ironCrate

2012-11-30 Thread Vincent Torri
On Sat, Dec 1, 2012 at 6:49 AM, NightStrike wrote: > > > Really, I haven't seen any build system that I think is wonderful. > autotools works for us, but it's not great. I've used a lot... even > scons. just for curiosity : what do you think of jam or one of its derivatives (ftjam, bjam, etc...)

Re: [Mingw-w64-public] ironCrate

2012-11-30 Thread NightStrike
On Fri, Nov 30, 2012 at 12:49 PM, Pau Garcia i Quiles wrote: > > > On Fri, Nov 30, 2012 at 3:29 PM, NightStrike wrote: > > [...] > >> >> In the cmake world, to do the same thing, Dave has to be a lot more >> knowledgeable of the internals of our project. He needs to know what >> languages we use

Re: [Mingw-w64-public] ironCrate

2012-11-30 Thread NightStrike
On Fri, Nov 30, 2012 at 12:36 PM, deneme.true wrote: > Hello, > > As I know, wxWidgets uses bakefile(http://www.bakefile.org/index.html) > system. Probably, bakefile is good for cross building of Makefiles for > nmake,mingw-make,make etc. This is intriguing. Can you give some detail on how it wo

Re: [Mingw-w64-public] ironCrate

2012-11-30 Thread JonY
On 12/1/2012 09:32, Pau Garcia i Quiles wrote: > >> When I want to compile an autotools project, I need sh, which as you have >>> already said, is only half-legged available on Windows. And that's the >>> whole point of CMake, especially when Visual C++ is in the middle. Sure, >>> you can generate

Re: [Mingw-w64-public] ironCrate

2012-11-30 Thread Pau Garcia i Quiles
On Sat, Dec 1, 2012 at 1:15 AM, JonY wrote: I tried cmake, it didn't like that I was trying to use MSVC inside > Cygwin by making too many assumptions in the generated makefile. The > produced Makefile was not gmake compatible. > > I thought cmake was supposed to be better than autotools in the r

Re: [Mingw-w64-public] ironCrate

2012-11-30 Thread JonY
On 12/1/2012 06:49, Pau Garcia i Quiles wrote: >> Now of course, we could >> try to provide these system-specific files that cmake should be giving >> us for free, but then we'd have to maintain (thus somehow be able to >> test) every conceivable system that our users might have or want to >> use.

Re: [Mingw-w64-public] ironCrate

2012-11-30 Thread Pau Garcia i Quiles
On Fri, Nov 30, 2012 at 3:29 PM, NightStrike wrote: [...] > In the cmake world, to do the same thing, Dave has to be a lot more > knowledgeable of the internals of our project. He needs to know what > languages we use, what compilers we need, how to call them, how to set > them up, what the di

Re: [Mingw-w64-public] ironCrate

2012-11-30 Thread deneme.true
Hello, As I know, wxWidgets uses bakefile(http://www.bakefile.org/index.html) system. Probably, bakefile is good for cross building of Makefiles for nmake,mingw-make,make etc. -- Keep yourself connected to Go Parallel: T

Re: [Mingw-w64-public] ironCrate

2012-11-30 Thread NightStrike
On Fri, Nov 30, 2012 at 10:13 AM, Zouzou wrote: > On 30/11/12 15:29, NightStrike wrote: >> In the autotools world, there is a very defined and extremely enforced >> concept that above all, our goal is to make it *TRIVIAL* for the end >> user to compile your software. Now let's clarify this. The e

Re: [Mingw-w64-public] ironCrate

2012-11-30 Thread Zouzou
On 30/11/12 15:29, NightStrike wrote: > In the autotools world, there is a very defined and extremely enforced > concept that above all, our goal is to make it *TRIVIAL* for the end > user to compile your software. Now let's clarify this. The end user > is the guy who knows nothing about developme

Re: [Mingw-w64-public] ironCrate

2012-11-30 Thread NightStrike
On Mon, Nov 12, 2012 at 3:22 AM, Xiaofan Chen wrote: > On Mon, Nov 12, 2012 at 3:55 PM, Pau Garcia i Quiles > wrote: >> As for your concerns about CMake being available or not: it's >> available from all Linux and BSD variants I know because more and more >> projects are moving to CMake because m

Re: [Mingw-w64-public] removing .la files from the automated builds

2012-11-30 Thread NightStrike
On Tue, Nov 13, 2012 at 2:03 AM, Vincent Torri wrote: > Hey > > I thought that this problem was fixed, but it seems it is not. The > automated builds still have the .la files. Can you remove them, please > ? > > Adrien suggested to use, with gnu tar : --wildcards --exclude="*.la" > > thank you Th

Re: [Mingw-w64-public] __HrLoadAllImportsForDll problems

2012-11-30 Thread NightStrike
On Fri, Nov 23, 2012 at 9:13 AM, Ian Lynagh wrote: > > Hi all, > > I'm trying to use __HrLoadAllImportsForDll with delay loading DLLs, but > I have not been able to make it work. I wonder if anyone could help me > please? Are you still having issues? > It seems that gcc makes an empty "Delay Imp

Re: [Mingw-w64-public] Upcoming Ruby 2.0 for Windows will be compiled with mingw-w64

2012-11-30 Thread NightStrike
On Tue, Nov 27, 2012 at 10:33 AM, Luis Lavena wrote: > Hello, > > Over the past few months we (RubyInstaller team) have been compiling > upcoming version of Ruby 2.0 with mingw-w64 in our automated CI > environment: > > http://ci.rubyinstaller.org/ Fantastic! Please join us on irc://irc.oftc.net

Re: [Mingw-w64-public] Software built with MinGW64

2012-11-30 Thread NightStrike
On Tue, Nov 27, 2012 at 6:47 AM, Giovanni Remigi wrote: > Here a list of some other software compiled with MinGW64 > > GraphicsMagick - http://www.graphicsmagick.org > ImageMagick - http://www,imagemagick.org > Boost - http://www.boost.org > Botan - http://botan.randombit.net > Qt 4.8.3 - http://q

Re: [Mingw-w64-public] Software built with MinGW64

2012-11-30 Thread NightStrike
On Tue, Nov 27, 2012 at 10:37 AM, Giovanni Remigi wrote: > Thanks a lot for the review. I'm not a C++ builder expert as you see :-) Thanks for your support :) > Any suggestion to change the toolchain structure to build both in 32 and 64 > bits? That would require building a multilib toolchain.