Gabriel M. Beddingfield wrote:
>> just the packagers need to compile it. That was the point with "more
>> flexible on linux"..
> You're right... but I also don't think there should be two build systems,
> so I thought it was worth talking about. In addition, I think our
> Sconstruct file could use some major restructuring.
> * 2 build systems: For getting out 0.9.4, just
> simply having 2 build systems may be the best
> and most stable option. Put all the files
> out there and add clear instructions in
> README or INSTALL.
Maybe the most won't even notive that there 2 build systems since there
is no "configure" script.
I don't think that a lot of users now what the .pro files are and how to
get a makefile of them.
So it should be fine to use both and document it.
I'm going to prepare that tonight, at least i'm going to move the qmake
files to trunk, create a patch for the windows change and document
> * scons: Figure out how to make scons work for
> Windows, OSX, and Qt. Possibly take the oppor-
> tunity to restructure some things. (Possibly
> * Raw qmake: Configure by manually editing a file
> like config.pri
> * autoconf/qmake: The 0.9.3 autoconf/qmake scheme
> may have been more complicated than it needed
> to be. Maybe? Perhaps a more simple setup could
> be developed.
> * script/qmake: Write our own configure script to
> drive qmake. We could do python, bash, whatever.
> * waf: There seems to be a mass exodus in the
> Linux Audio commuinty from scons to waf. waf
> is a fork of scons.
> * cmake: KDE dumped scons for cmake in the KDE 4
> rewrite. However, when I dug into this... the
> reasons were peculiar to KDE and other Very
> Large Projects.
My favourite would be waf and script/qmake. From a users viewpoint i
like waf very much, the progress bar is handy if you're building big
packages on older machines. I threw an eye on waf some months ago, but i
couldn't find any non-trivial examples which make use of QT. And we
have to make sure that the waf QT module is not exactly the one from
Another benefit of waf is that its just one script - not a whole system
like scons. That makes it easier to distribute it with hydrogen.
The script solution would be flexible and not a lot of work. I'm very
open for that..
Of course it would be the best to figure out how to built it properly
with scons. I don't have a lot of time at the moment,
but i would look for that in some weeks.
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> Hydrogen-devel mailing list