On Apr 16, 2010, at 8:09 AM, Nikolas Zimmermann wrote:
Am 16.04.2010 um 16:44 schrieb Adam Treat:
I am very skeptical that it is feasible to write a gyp generator
that would
output QMake files. There is a log of magic in those QMake files.
My sense is
that it would not be trivial by any means.
Plus, I don't like the idea of a meta-meta generators. Seems way
to mickey-
mouse to me.
Agreed to a certain degree. Using gyp/whatever to generate qmake
files, to generate Makefile/Xcode files etc seems akward to me as
well.
What we really need to resolve is adding/removing files from
compilation, that's the most common
task that has to be done in 5+ build systems at the moment.
Besides adding, removing and renaming, the other thing that's really
hard is adding a new generated source rule. Although this is not
needed as frequently, I think anyone adding a new code generator
script that has to work across all WebKit ports would have a hellish
time of it right now.
If I had to do it myself, I would just skip any ports that don't use
DerivedSources.make.
So I have a new proposal:
1) Maintain a list of headers/source files to be compiled for ALL
platforms (ie. dom/Node.cpp, etc..)
2) Keep all existing Makefile.am, WebCore.pro etc files as
"templates", ie. WebCore.pro.template, with a special
variable somewhere marking the $$HEADER_LIST$$ and the $
$SOURCE_LIST$$
3) Use a script that generates individual build files (eg.
WebCore.pro) from WebCore.pro.template, it only
needs to insert the file list with the correct syntax in the
correct places
4) Keep all platform specific files to be compiled in the individual
build system files (eg. WebCore.pro.template)
I think we'll never find a consensus on a single build system, there
are too many different needs. I only care
about the most repetitive work in order to keep the build system
up2date: adding/removing cross-platform files.
I think the proposal above does not handle the derived sources
problem. It also doesn't handle files that are shared between multiple
ports but not all ports. It also doesn't provide project files that
are directly usable by IDEs, on platforms where that is the standard
way to do development.
Once we start solving problems like that, I suspect we end up with
something closer in complexity to Gyp or CMake.
Regards,
Maciej
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
