Re: [Boost-users] boost build interface
FWIW this doesn't have to be a windows only GUI. We could use the QT widget set and make this portable to most platforms supported by boost. Note, that Qt is LGPL now, so you could even include this into commercial distributions if needed. Am 08.04.2009 um 16:10 schrieb Green, Jason M NSWCDL, W33:
Not that I am volunteering, but it isn't that hard to come up with a simple dialog based mfc project that would set up the commands to properly run the boost build.
Rudolf Leitgeb wrote:
FWIW this doesn't have to be a windows only GUI. We could use the QT widget set and make this portable to most platforms supported by boost. Note, that Qt is LGPL now, so you could even include this into commercial distributions if needed.
Qt application with static linking is gonna weight about 2MB. Does this sound acceptable? Probably it is. The KDE project is working on windows installer for KDE, which is capable of getting necessary third party libraries. I imagine this might be good for Boost -- for example, libz is not commonly installed on Windows. However, I have no idea how easy it would be to adjust that. - Volodya
Qt application with static linking is gonna weight about 2MB. Does this sound acceptable? Probably it is.
The KDE project is working on windows installer for KDE, which is capable of getting necessary third party libraries. I imagine this might be good for Boost -- for example, libz is not commonly installed on Windows. However, I have no idea how easy it would be to adjust that.
It depends on what we aim for. If we want the perfect GUI which allows complete noobs to install boost on any platform, we're up for a huge task, and as far as I have read here, while a few are excited about HAVING a graphical installer, much fewer are eager and ready to WRITE one. IMHO an installer in its first stage should: - allow picking on of a few configurations (debug, release, shared, static) - (optionally) allow picking a subset to be built (what bcp does now) - allow picking a directory where the results are written to - allow picking the C++ compiler to be used (gcc, mingw, icc, vs, ...) - allow addition of custom compiler switches - tell the user if necessary libraries are missing, optionally locations where those libraries can be found - point the user to this mailing list if the configuration he/she needs is not supported by the GUI, e.g. cross compilation, new compilers, new platforms, whatever ... If we could settle with this minimal feature set, we could easily slap together a GUI front end, or alternatively, do the same with a web page, as dhruva suggested (I like the idea a lot). Rudi
participants (2)
-
Rudolf Leitgeb -
Vladimir Prus