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 b
This is due to Apple using specific features in XCode / VS. But for
the rest of the ports (Qt, GTK, Wx, BAL...), we could stick to a
single buld system, CMake or another
And we could hope that Apple someday helps CMake addressing these
specific features so that everybody uses the same system
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
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 scr
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 cha
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 and
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
X
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 à 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
Hi Maciej,
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 swit
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 am
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 for
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 every
On Nov 12, 2007 2:48 AM, Mike Hommey <[EMAIL PROTECTED]> 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
> > f
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. The
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 c
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 t
goal.
Regards,
> De : Alp Toker <[EMAIL PROTECTED]>
> Date : 12 novembre 2007 04:34:48 HNEC
> À : [EMAIL PROTECTED]
> Objet : [webkit-dev] Moving away from qmake
>
> The existing qmake-based build system is shared by the GTK+ and Qt ports.
>
> Until recently, this arrangeme
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 Trolltech
> 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 qma
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
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
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 o
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 of a little inconvenience for users (in the
sense of applica
24 matches
Mail list logo
