On Wed, Dec 15, 2010 at 11:08 AM, Dmitrijs Ledkovs <dmitrij.led...@ubuntu.com> wrote: > To define a new dpkg architecture. > To define a new name. > Often it is necessary when GNU triplets is doesn't exist, not > standardized or multiple triplets are used. > > E.g. Gnu/kfreebsd port and msys (no triplet in upstream git checkout > of config.guess and config.sub) > >> What's wrong with using the existing GNU triplet? >> > > Nothing is wrong. We can use <cpu>-w64-mingw32 for GNU triplet and > make up any debian name for it. It is best if debian name has meaning > is consistent with other similar arches.
To each his own. I would think that the debian naming scheme would want to have as big an intersection as possible with the GNU naming scheme, but that's just me. I'll drop the issue. >> >>>> That part should eventually just be called "windows", for instance in >>>> x86_64-w64-windows. >> No, I was referring to the GNU triplet. We've talked extensively >> about the logical collapse into <cpu>-<vendor>-windows, where the >> vendor key determines if it's from mingw.org, mingw-w64.sf.net, or any >> other place. >> > > Currently config.sub prefers winnt > > -windowsnt*) > os=`echo $os | sed -e 's/windowsnt/winnt/'` > ;; > > And I don't see config.sub and config.guess recognising <vendor>-windows. That's because it doesn't. I was just saying that it's where we should go in the future. I have no idea if it will ever happen. > Creating a patch which will make config.sub and config.guess recognise > <cpu>-w64-windows, <cpu>-mingw-windows, <cpu>-msys-windows and > <cpu>-cygwin-windows is IMHO a radical change. Loads of software will > needs to be patched to recognise vendor tag and not depend on *mingw32 > in their configure scripts. Well, to transition it properly, you'd define an alias first, then eventually deprecate and phase out the old one over a long period of time. > Would you be willing to provide a patch against config.sub and > config.guess? Such patch could be integrated into autotools-dev in > Debian and the rest of software can be patched as described above. It > will be a painful transition requiring loads of work. I cannot commit > to doing it. Can't. Anonymous contributions aren't accepted. > I'd rather use windows-<vendor> as Debian OS Name and continue using > existing Gnu tripplets (-w64-mingw32, -pc-mingw32, *-cygwin, *-msys) > >> I don't undrestand the naming structure or purpose of these >> debianisms, but if you start out fresh using "windows" to signify >> windows platforms, that seems logically sound. >> > > *nod* So is the best technical solution right now to create > <cpu>-<vendor>-windows GNU tripplet and slowly start patching > config.sub, config.guess and all of upstream projects? That's very debatable. I personally think it is, if you ignore 1) the politics of the matter, and 2) the ginormous amount of work required to update everything (though the transitional approach I mentioned eases that somewhat.) > Are cygwin/msys/mingw people willing to support new triplet naming scheme? Doubtful. This is a topic that will inevitably be bikeshedded to death. In fact, that's the very reason we started using the vendor tag for mingw-w64.sf.net-specific stuff. We got tired of debating with people as to what the $os part of the triplet should be. Heck, getting the "32" part of mingw32 changed to a wildcard (ie, mingw*) was difficult enough. It's hard to change the past, and even harder to change long standing traditions. However, if it's at all possible, I fully support a change to triplets that actually make sense. > I personally would rather work now using existing GNU tripplets (e.g. > <cpu>-w64-mingw32), call debian arch as win[dows|nt]-<vendor> and > continue like that. At a later date we can switch the gnu ports to the > fresh GNU tripplets <cpu>-<vendor>-windows onces cygwin, mingw and > msys upstream agree to support that. The first transition can happen > within Debian archive, I just don't want Debian to be the only one to > have "a different GNU triplet not used by anyone else". That's probably a good idea, though I doubt anyone will step up and push the config changes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
