2013/5/30 Adrien Nader <adr...@notk.org>
> On Thu, May 30, 2013, Ruben Van Boxem wrote:
> > 2013/5/20 Adrien Nader <adr...@notk.org>
> >
> > > Hi,
> > >
> > > I've started working on a download page for the website. Currently the
> > > download links point directly to the sourceforge file listing but
> that's
> > > not enough for the users to be able to chose the right(tm) download.
> > >
> > > The page I've done is at:
> > > http://notk.org/~adrien/picker.php
> > >
> > > It's mostly an HTML shim with javascript and a list of toolchain
> > > descriptions to generate the page content. The php bit is only there to
> > > provide an "include" directive to easily and cleanly provide a default
> > > download list if the user doesn't have JS[1].
> > >
> > > As you can see on the page, besides the layout which isn't perfect, the
> > > toolchain descriptions are completely wrong. If you maintain such a
> > > toolchain and wish to be listed on the download page, please provide me
> > > with a toolchain description.
> > > The process to update the list on the server is not decided yet but for
> > > now, please reply to this email with JS code that creates one or more
> > > objects like in http://notk.org/~adrien/toolchains.js .
> > >
> > > There should also be a way to filter based on compile-time
> > > configuration. In particular, the setting for C++ exception matters a
> > > lot.
> > > I haven't added this yet because I lack visibility about them (how many
> > > of them are there in practice?). As such, please also mention such
> > > specific settings that you might have for your toolchains and once
> there
> > > is a clearer picture, the code can follow.
> > >
> > > Don't hesitate to mention anything that may be missing on my page (no,
> I
> > > won't add ponies).
> > > For additional reference, here is a page that Jon_Y had done some time
> > > ago with a similar goal and a very different implementation:
> > > http://mingw-w64.sourceforge.net/picker.php
> > >
> >
> > I don't mean this in a bad way, but jon_Y's page seems a lot more direct
> to
> > me. Perhaps a bit of explanation about what target,host, etc. mean, but
> > pull-down menus seem more intuitive than checkboxes as far as filtering
> > goes.
>
> No offense taken. The page I've made tries to show much more information
> and that comes at the cost of more complexity.
> There are many many differences between the available toolchains and
> it's simply impossible to have a proper coverage while keeping
> everything even remotely exhaustive without adding more things to the
> page. There is more than half-a-dozen sources of binaries.
>
> The page I've linked to is by no mean final however. It clearly needs a
> "frame", i.e. theming, better explanations, ... What is currently there
> is more like an engine. Fighting javascript's non-existant error
> reporting along with doing everything through the DOM has taken much
> more time than theming could need.
>
> > I don't think it is a good idea to keep Linux distro's toolchains on this
> > list. There will be many, and they will continually change and be updated
> > etc. How would you track all these very distro-specific changes? Same
> with
> > "additional software". Traditionally on Windows, this has been provided
> by
> > the projects themselves, not the toolchain. Unless you have a repo
> bulging
> > with everything one might need, I don't really see how this could help.
>
> The toolchains of Linux distributions don't change once they're released
> and I've kept Fedora Rawhide out of the list on purpose.
> In any case, they cannot change more often than the Automated Builds do
> and it will be the responsibility of the distribution maintainers to
> provide the relevant information in a suitable format (more on this
> below).
>
Let's get things straight: the number of Linux distros providing a
MinGW-w64 toolchain is only going to keep increasing (currently:
Debian+derivatives, Ubuntu+derivatives Fedora+relatives, OpenSUSE, Arch,
gentoo, etc...) I don't see any of these have much interest in keeping yet
another web page in sync. I'm sure there will be exceptions, but you can't
rely on exceptions. Besides, they all have their own package management
functions that might advertise mingw-w64 in one way or another depending on
a user search. Linux users don't typically use google to find their
packages. This whole updating becomes even more undoable when you factor in
3rd party packages, which a distro may or may not provide, and update.
I'm just trying to warn you for trying the nigh impossible for IMHO little
value.
>
> As for the additional softwares, I strongly believe they matter. C++
> makes this even more important because of the incompatible exception
> handling mechanisms.
> I've also never enjoyed having to hunt for unreliable prebuilt binaries
> on tens of websites and software authors don't usually enjoy having to
> build binaries themselves either (tbh, I've seen reactions vary between
> disliking it, hating it and despising it).
>
I think the regular MinGW(-w64) developer will either be or become quickly
accustomed to building all his/her dependencies from source. Granted,
that's far from ideal, but there'd need to be a huge packaging effort to
remedy this.
>
> However, I'm open about that: the download page is meant to serve the
> users. I'll ask people.
>
> > To provide some of the info you required:
> > - There are three exception handling mechanisms: sjlj (slowest, both 32
> > and 64-bit). dw2 (faster, 32-bit only, no exceptions can be thrown
> accross
> > callbacks), and seh (best, 64-bit only).
> > - There are two libgcc threading variants: win32 and posix. Only the
> > latter allows for the C++11 library's threading to be used.
>
> Thanks, I completely forgot to mention the exception handling
> mechanisms.
> About the threading variants, what is the disadvantage of the posix one?
> Does it depend on pthreads?
>
Yes, and it makes libgcc pull in winpthreads, which makes C code depend on
winpthreads. Not ideal, but IMO not a big deal, but other people tend to
disagree.
>
> > On to the page itself:
> > - I don't think it's a good idea to select on binutils/mingw-w64 trunk
> > versions; some don't use snapshots, information is overkill anyways
> etc...
> > - Perhaps rename "CRT" to "MinGW-w64" or "MinGW-w64 headers and
> > libraries". Just because I'm pedantic about this stuff ;-)
>
> I'm unsure whether the binutils version should be displayed: I can't
> remember anything that would make someone strongly prefer one version
> over another one. Does anyone remember such a case recently?
> I believe the mingw-w64/CRT version matters however. The fact that a
> toolchain doesn't provide the right API can be a blocker. OTOH it might
> not be needed as a filter. I'm going to ponder that.
>
Yes, main versions (v1, v2, v3 (trunk)) matter. Dated svn snapshots get
unwieldy. Perhaps a date on the package itself could replace the composing
software's dates.
>
> > How do you plan on updating the picker when e.g. I release a new set of
> > binaries?
>
> Plans, not really. At least, nothing has been decided yet.
>
> The most practical input format is Javascript/JSON. For downloads which
> get updated infrequently, doing the update by hand will be fine. For
> downloads which get daily updates (like the automated builds) it will
> have to be automated, maybe a cron job on sf.net or pulling the data as
> JSON directly from the downloads.
>
> This picker.php page actually works with JS disabled because I've used
> it with JS on, dumped the DOM that got generated from the toolchains
> data and put that inside a file that gets included by PHP.
> That's not something that would be easy to automate but it could be done
> by hand once a week (it takes less than 20 seconds) and the downloads
> would only lag by up to 1 week for people with JS off.
>
Is there really a non-negigible amount of people running a browser without
JS? This isn't the '90s.
>
> As I said, nothing is set: it's difficult to foresee everything and I'm
> reluctant to try to automate something until the requirements are clear.
>
The automation will be hard without the toolchain contributor's help.
I wouldn't mind keeping my toolchain's info up to date. I doubt, though,
that *everyone* will cooperate, unfortunately.
Let me know if you need me to provide some toolchain info formatted in
whatever you need.
Ruben
>
> > Cheers,
> >
> > Ruben
> >
>
> Thanks,
>
> --
> Adrien Nader
>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
