I think everyone's got their own build systems, LRN has one,
mingw-builds have theirs, Ruben has his, you've got yours (kudos for
using PowerShell though, I didn't know anyone did that ;-))
I wish I had the time to investigate porting either nix or homebrew to
Windows, but that'd just be another build system I guess, other than
that, porting the mingw-builds system to be able to use Linux and/or
Darwin as the build system would be really useful for someone to have
a try at.
On Fri, Jul 12, 2013 at 9:41 PM, Jon <jon.forums@...> wrote:
> On Fri, 12 Jul 2013 19:43:04 +0200
> Kai Tietz <ktietz70@...> wrote:
>> 2013/7/10 Jon <jon.forums@...>:
>> >> > > While the question about what current users are using is already hard to answer, there's IMO a bigger one: What _potential_ users are there that aren't already using mingw-w64 :) I started looking into mingw-w64 maybe a year ago, only to find out that
>> >> > > - there's no 'official' installer/ toolchain
>> >> > > - there are a whole bunch of 'personal' builds & mingw-w64 derived projects
>> >> > > - different projects provide a myriad of different gcc versions x architecture x exception handling mechanism x threading library combinations (and again, little hints on what is the 'recommended' configuration for most users).
>> >> > >
>> >> > ...SNIP...
>> >> >
>> >> > I do not say that not offering any option is the right way. But there
>> >> > should be something what is "default". And the "default" should be
>> >> > offered as that. It should be much more visible, and available in a
>> >> > click or two from the homepage. And last but not least, the "default"
>> >> > should not be tagged as a personal build. You should minimize the number
>> >> > of question he needs to answer to get "just some compiler to build my
>> >> > program with".
>> >> >
>> >> > To summarize, IMO, mingw-w64, although technically as good as it is,
>> >> > emits bad signals to newcomers. Unfortunately, it has always been
>> >> > repelling for new users and, I believe, it is also the reason why
>> >> > mingw-builds (although also not ideal for sure) succeeded so easily. It
>> >> > simply filled the gap in the demand, which you never attempted to fill.
>> >> I believe everyone will concur.
>> >> ...SNIP...
>> >> In any case we now have the question: what would be official or even
>> >> advised?
>> > This is not a technical issue. It's primarily a mingw-w64 project leadership and
>> > simplification challenge.
>> > It's not helpful that neither Kai nor JonY has definitively weighed in on whether
>> > an official mingw-w64 default toolchain makes sense. Actually, that's not true.
>> > Awhile back Kai was very involved with announcing Ruben as the new build release
>> > mgr. I interpreted Kai's actions to mean that he felt mingw-w64 needed a maintained,
>> > official, easy-to-use default toolchain in addition to the automated testing builds.
>> Well, I assumed I was clear about that already. IMO it is absolutely
>> necessary that we (mingw-w64) are providing an official
>> toolchain-version, which we are recommenting.
>> To be clear here, those toolchain-releases aren't mingw-w64 releases.
>> The mingw-w64 releaes are just releases of our repository, not that of
>> combinations with other ventures.
>> And exactly this might be confusing here for some people. A pre-build
>> toolchain release is always just "one" variant of a combination using
>> our stuff with other ventures. That makes such releases so hard to be
>> marked as "recommented".
>> Nevertheless I agree completely that we have to provide such pre-build
>> toolchains, so that users have an easier access to our work.
>> > But "interpreting" or "implying" or "inferring" is not useful. Explicit clarification
>> > from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why this hasn't
>> > happened is that both already have too much on their plate and don't want to set the
>> > expectation that either will be responsible for implementing and maintaining an official
>> > toolchain like JonY appears (aweome) to be doing at http://cygwin.mirrors.pair.com/release/gcc4/
>> > The old speak-up-and-get-stuck-with-it paradox ;)
>> > That's OK, and is why I believe the first step needs to be Kai/JonY saying (a) "The
>> > mingw-w64 project needs an official, easy-to-use toolchain", (b) "Neither of us
>> > have the bandwidth to implement/maintain it", and (c) "We're actively looking for
>> > a new committer to take on this role. If this is going to happen and be sustainable,
>> > we need your help."
>> a) yes, b) yes (we need people in charge for that and doing this
>> reliable), c) yes, we are actual in discussion with mingw-builds
>> venture to go together (and/or co-operate more closely).
>> > Or say "The current situation is fine; mingw-w64 doesn't need an official toolchain."
>> No, we should provide Windows native pre-build toolchain
> Fantastic. These days I don't get to contribute to OSS as much as I'd like, but if it would be
> useful, I'll carve out time to test/provide feedback on any toolchain build tool you and the
> mingw-builds team come up with.
> I'm fixated by easy-to-use port-like build automation tools that do the typical cycle of
> download -> verify -> patch -> configure -> build -> stage -> package
> and am continuously toying with one of my own little monsters for building common libs
> with mingw-w64:
> So, I'm curious on what you guys are building and would like to help, even if it's just easy-of-use
> testing of the build tool.
> Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
> http://jonforums.github.io/ | http://thecodeshop.github.io/
> twitter: @jonforums
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> Mingw-w64-public mailing list