Re: [Mingw-w64-public] "Autotools sux" [WAS: recipes for automated 32bit mingw build?]

On 8/10/2011 01:12, Jon wrote: >> On 8/9/2011 22:19, Ruben Van Boxem wrote: >>> 2011/8/9 Earnie : Ruben Van Boxem wrote: >> Heh, the solution is to use autotools, all the way, never >> compromise on quality. There are a lot of packages too pretentious >> to use autotools... >>

Re: [Mingw-w64-public] "Autotools sux" [WAS: recipes for automated 32bit mingw build?]

> On 8/9/2011 22:19, Ruben Van Boxem wrote: > > 2011/8/9 Earnie : > >> Ruben Van Boxem wrote: > >> > Heh, the solution is to use autotools, all the way, never > compromise on quality. There are a lot of packages too pretentious > to use autotools... > >>> > >>> Bull shit. Hardly a so

Re: [Mingw-w64-public] Release build infrastructure

On 8/9/2011 23:49, Jon wrote: >> On Tue, Aug 9, 2011 at 10:44 AM, Jon wrote: You guys rock, let that be clear ;-) Kai and me have been discussing a proper release build setup for mingw-w64. I would become the release packager dude that makes sure proper releases are... rel

Re: [Mingw-w64-public] Release build infrastructure

> On Tue, Aug 9, 2011 at 10:44 AM, Jon wrote: > >> You guys rock, let that be clear ;-) > >> > >> Kai and me have been discussing a proper release build setup for > >> mingw-w64. I would become the release packager dude that makes sure > >> proper releases are... released. > >> > >> ...SNIP... > >

Re: [Mingw-w64-public] Release build infrastructure

On Tue, Aug 9, 2011 at 10:44 AM, Jon wrote: >> You guys rock, let that be clear ;-) >> >> Kai and me have been discussing a proper release build setup for >> mingw-w64. I would become the release packager dude that makes sure >> proper releases are... released. >> >> ...SNIP... >> >> Any construct

Re: [Mingw-w64-public] Release build infrastructure

On Mon, Aug 8, 2011 at 5:27 PM, Farkas Levente wrote: >>    --> binutils: latest trunk is the only sensible version > > does it means you always send all mingw/windows specific patches to > binutils upstream and those are always merged? if not it'd be useful to > keep all patches for the a given r

Re: [Mingw-w64-public] "Autotools sux" [WAS: recipes for automated 32bit mingw build?]

On 8/9/2011 22:19, Ruben Van Boxem wrote: > 2011/8/9 Earnie : >> Ruben Van Boxem wrote: >> Heh, the solution is to use autotools, all the way, never compromise on quality. There are a lot of packages too pretentious to use autotools... >>> >>> Bull shit. Hardly a solution. Sorry for

Re: [Mingw-w64-public] Release build infrastructure

> You guys rock, let that be clear ;-) > > Kai and me have been discussing a proper release build setup for > mingw-w64. I would become the release packager dude that makes sure > proper releases are... released. > > ...SNIP... > > Any constructive thoughts are welcome, and help in getting the >

Re: [Mingw-w64-public] "Autotools sux" [WAS: recipes for automated 32bit mingw build?]

2011/8/9 Earnie : > Ruben Van Boxem wrote: > >>> Heh, the solution is to use autotools, all the way, never >>> compromise on quality. There are a lot of packages too pretentious >>> to use autotools... >> >> Bull shit. Hardly a solution. Sorry for the direct words, but you >> can't possibly force a

Re: [Mingw-w64-public] "Autotools sux" [WAS: recipes for automated 32bit mingw build?]

Ruben Van Boxem wrote: >> Heh, the solution is to use autotools, all the way, never >> compromise on quality. There are a lot of packages too pretentious >> to use autotools... > > Bull shit. Hardly a solution. Sorry for the direct words, but you > can't possibly force autotools on the world. I ha

Re: [Mingw-w64-public] Release build infrastructure

2011/8/8 Farkas Levente : > On 08/08/2011 05:02 PM, Ruben Van Boxem wrote: >>  - What we agreed on about versioning: >>    --> mingw-w64 should adopt a semi-rolling release model. It's >> source only, so (Linux) packagers should just pick a (release) branch >> and use its latest revision. > > it's