On Nov 12, 2007, at 1:26 PM, Timothy Hatcher wrote:
We could add a script that would add/remove/rename files in all the
project files for the various build systems.
Yeah, that's what I had in mind, more than a meta-build-system. If we
had that, it would remove 90% of the pain of multiple
On Mon, Nov 12, 2007 at 03:34:48AM +, Alp Toker [EMAIL PROTECTED] wrote:
An unforeseen benefit of the new build system is that it is modular,
rather than monolithic, and has no dependency on GLib/GTK+ or any other
framework. This means that it will now be possible to use JavaScriptCore
as
Mike Hommey wrote:
On Mon, Nov 12, 2007 at 03:34:48AM +, Alp Toker [EMAIL PROTECTED] wrote:
An unforeseen benefit of the new build system is that it is modular,
rather than monolithic, and has no dependency on GLib/GTK+ or any other
framework. This means that it will now be possible to
If we cannot reach a conclusion, the GTK+ port will most likely go
ahead and switch to autotools.
I'm one person with a highly niche port, but for what its worth I'd
support a move to autotools.
I'm doing a port to AROS, which currently means cross-building WebKit on
Linux. I opted to use
I am working on a port of WebKit on Qt to a PowerPC platform. Please
make sure that we don't break the Qt port in this switch. I am
comfortable with autotools, so that is not a big deal for me. I am
concerned, however, that this will cause a fork with the work being
done by the
Hello,
Here is my experience with cmake, so I hope it may help you to decide
which build system is the best for you.
Its first advantage is that it is cross platform. So you can imagine
in a long term approach to have a unified build system between
GTK/Qt/Wx/Win and mac.
Another advantage is that
On Monday 12 November 2007 14:00:31 Charles Woloszynski wrote:
I am working on a port of WebKit on Qt to a PowerPC platform. Please
make sure that we don't break the Qt port in this switch. I am
comfortable with autotools, so that is not a big deal for me. I am
concerned, however, that this
On 13/11/2007, at 00:00, Charles Woloszynski wrote:
I am working on a port of WebKit on Qt to a PowerPC platform.
Please make sure that we don't break the Qt port in this switch. I
am comfortable with autotools, so that is not a big deal for me. I
am concerned, however, that this will
Ok, thanks for the feedback. I have had some issues with the cross-
compilation of WebKit (dftables being built for the cross-platform,
not the native platform). Any chance I can get someone doing the
WebKit Qt port to address this? I don't know qmake well enough to
make the changes.
I refactored all the Unicode handling to run behind a abstract interface.
So no direct ICU calls.
Its a lot of little patches all over the place and a thankless job.
Its a lot of work so email me if your interested.
I was also looking at repacling icu with glib/pango.
Its not clear you get
On Nov 12, 2007, at 5:28 AM, Mark Rowe wrote:
On 13/11/2007, at 00:00, Charles Woloszynski wrote:
I am working on a port of WebKit on Qt to a PowerPC platform.
Please make sure that we don't break the Qt port in this switch. I
am comfortable with autotools, so that is not a big deal
On Nov 12, 2007, at 11:33 AM, Maciej Stachowiak wrote:
On Nov 12, 2007, at 5:28 AM, Mark Rowe wrote:
On 13/11/2007, at 00:00, Charles Woloszynski wrote:
I am working on a port of WebKit on Qt to a PowerPC platform.
Please make sure that we don't break the Qt port in this switch.
I
Le 12 nov. 07 à 20:55, Kevin Ollivier a écrit :
I'm fairly sure this would be easy enough for MSVS because of its
XML nature. In fact, I did things the opposite way (converted MSVS
XML - Bakefile) when I first started adding in the wx port, so that
we kept up-to-date with any changes to
On 13/11/2007, at 07:10, Jean-Charles VERDIE (Pleyo) wrote:
Le 12 nov. 07 à 20:55, Kevin Ollivier a écrit :
I'm fairly sure this would be easy enough for MSVS because of its
XML nature. In fact, I did things the opposite way (converted MSVS
XML - Bakefile) when I first started adding in
Le 12 nov. 07 à 21:12, Mark Rowe a écrit :
On 13/11/2007, at 07:10, Jean-Charles VERDIE (Pleyo) wrote:
Le 12 nov. 07 à 20:55, Kevin Ollivier a écrit :
I'm fairly sure this would be easy enough for MSVS because of its
XML nature. In fact, I did things the opposite way (converted MSVS
Apple needs to use native Xcode and VS projects to work with existing
build systems. So generating an Xcode or VS project is not useful.
On Nov 12, 2007, at 12:20 PM, Jean-Charles VERDIE (Pleyo) wrote:
I might be wrong but I think it's useful to be able to generate,
from the same sources
Kevin Ollivier [EMAIL PROTECTED] wrote:
[...] The tricky part AFAICT would be XCode, though, because
even if there is a scripted solution for this, it would probably need
to be run on a Mac where we have access to AppleScript or some other
scripting tool that can read and make changes
We could add a script that would add/remove/rename files in all the
project files for the various build systems.
On Nov 12, 2007, at 1:19 PM, David D. Kilzer wrote:
Kevin Ollivier [EMAIL PROTECTED] wrote:
[...] The tricky part AFAICT would be XCode, though, because
even if there is a
Hi David,
On Nov 12, 2007, at 1:19 PM, David D. Kilzer wrote:
Kevin Ollivier [EMAIL PROTECTED] wrote:
[...] The tricky part AFAICT would be XCode, though, because
even if there is a scripted solution for this, it would probably need
to be run on a Mac where we have access to AppleScript or
Hi Alp,
On Nov 11, 2007, at 7:34 PM, Alp Toker wrote:
The existing qmake-based build system is shared by the GTK+ and Qt
ports.
Until recently, this arrangement has not been too problematic for the
GTK+ porters, with the idea being that qmake makes life easier for
developers at the expense
20 matches
Mail list logo
