[webkit-dev] Build system for ports
Kevin Ollivier
kevino at theolliviers.com
Sat Apr 22 19:08:22 PDT 2006
Hi Justin,
On Apr 22, 2006, at 9:11 AM, Justin Haygood wrote:
> FIles to be compiled to be managed bny Bakefile, and custom VS2005
> build settings to be done manually
IMHO, it's not just build files we may want to be updated, though.
There are also include dirs, pre/post build steps, settings like
warnings/threading/etc., and I think at some point people will get
confused as to what in the VS2005 project file they are and aren't
supposed to modify. I think the most robust manner is to make sure
Bakefile is capable of generating whatever VS2005 build settings we
need, and then auto-generating the file. Then there is always one
place to go for changing the settings. Bakefile allows us to create
project-specific commands for only one project format, so we can have
VS2005-specific stuff in there.
Anyways, I realize there will need to be some tweaks to Bakefile
before this can happen, but I think it is overall the best approach
even if it takes a little more time to implement. Until it's ready,
I've got scripts to help keep the ports updated with changes in the
Win project.
Thanks,
Kevin
> On 4/22/06, Kevin Ollivier < kevino at theolliviers.com> wrote:
> Hi Justin,
>
> On Apr 19, 2006, at 6:02 AM, Justin Haygood wrote:
>
>> What would be nice is if it didn't outright replace the exiting
>> file, but examined it and added or removed files that need to be
>> added/removed. Since a VS project is just an XML afterall...
>
> What would be the gain, though? e.g. assuming Bakefile spits out a
> VS2005 project file exactly the same as the existing one, what
> would the code to synchronize rather than overwrite the file do for
> us? Or are you referring to synchronizing certain parts of the file
> with the Bakefile project, and leaving other parts to be maintained
> outside of Bakefile?
>
> BTW, as it turns out, there is a beta implementation of VS2005
> support that I've got a copy of. I hope to start playing with it
> sometime soon, but I'd like to have the existing changes reviewed
> and cleaned up first before playing with new format support.
>
> Thanks,
>
> Kevin
>
>> On 4/19/06, Kevin Ollivier <kevino at theolliviers.com> wrote:
>> Hi Justin,
>>
>> On Apr 18, 2006, at 10:40 AM, Justin Haygood wrote:
>>
>>> Everytime a new solutiion is converted:
>>> 1. The old Intellisense database is invalidated.. important for
>>> embedding as it makes looking up functions in .h files obsolete
>>> for the most part.
>>> 2. VC6 doesn't support manifests natively (it requires the
>>> hackish use of RC files), which VC2005 supports natively. If you
>>> want to use native common controls for instance, a VC6 project
>>> converted to VS2005 won't build if you embedded the required
>>> manifest, since VS2005 requires its own manifest to be included,
>>> and you're allowed only one (it will merge them together if you
>>> add the manifest to the VS2005 project file).. this is important
>>> when embedding into another app without having to use multiple
>>> solutions
>>> 3. You're still limited to what's available in a VC6 project,
>>> because it'll have to be upconverted everytime.
>>> 4. It's just messy
>>
>> Okay, thanks for letting me know. I of course don't think we
>> should replace existing project files until they can be replicated
>> "as is", but I was wondering how much of a difference it would
>> make for the ports. I'm going to check in with the Bakefile devs
>> and see how much more work will be involved before they can do a
>> release with VS2005 support.
>>
>> Thanks,
>>
>> Kevin
>>
>>> On 4/18/06, Kevin Ollivier <kevino at theolliviers.com > wrote:
>>> Hi Justin,
>>>
>>> On Apr 16, 2006, at 6:32 PM, Justin Haygood wrote:
>>>
>>>> Does bakefile generate Visual Studio 2005 solutions (not VC6
>>>> projects...) that can be used completely within the UI after
>>>> completition? I dislike having to drop to a command line when a
>>>> perfectly good GUI exists that makes the whole edit, compile,
>>>> debug phase work with one click of a button (just click debug
>>>> with an edited file and it will save it, compile it, and then
>>>> start debugging)
>>>
>>> VS2005 support is in development, but not finished yet. However,
>>> I was wondering what you meant about using the command line, as I
>>> imagine you're aware that VC6 projects can be opened in VC2005.
>>> I've been opening the VC6 projects in VS7.1 and VS8 in order to
>>> build WebCore, and it works just fine for me. Or does doing so
>>> somehow disable features in the IDE that I haven't run across yet?
>>>
>>> Thanks,
>>>
>>> Kevin
>>>
>>>> On 4/16/06, Kevin Ollivier < kevino at theolliviers.com> wrote:
>>>> Hi Mike and Timothy,
>>>>
>>>> On Apr 16, 2006, at 2:45 PM, Mike Emmel wrote:
>>>>
>>>> > bakefile generates xcode projects as I understand.
>>>>
>>>> It does spit out a project with all the files, etc., but there's a
>>>> lot of features still missing from it, so it can't be used as-is. A
>>>> fairly good Python hacker familiar with the XCode2 project format
>>>> might be able to whip something up without too much time, though.
>>>>
>>>> > Mike
>>>> >
>>>> >
>>>> > On 4/16/06, Timothy Hatcher < timothy at hatcher.name> wrote:
>>>> >>
>>>> >> This might be a good approach for Linux, Win32 and other ports,
>>>> >> but the Mac
>>>> >> side will likely need to stay all in Xcode projects. Xcode can
>>>> >> call out to
>>>> >> external Makefile/Bakefile targets, but when building
>>>> universal it
>>>> >> gets very
>>>> >> complicated. We would need to lipo our binaries in another build
>>>> >> phase
>>>> >> script at the end. That is just one of the major complexities
>>>> that
>>>> >> Xcode
>>>> >> handles for us that we know will always work with Apple's build
>>>> >> system.
>>>>
>>>> Yes, I know, I've written scripts to lipo wxWidgets together
>>>> because
>>>> the wxPython build system is autoconf-based. ;-) When the XCode2
>>>> backend for Bakefile is finished, though, we may be able to use
>>>> that
>>>> instead.
>>>>
>>>> Thanks,
>>>>
>>>> Kevin
>>>>
>>>> >> — Timothy Hatcher
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Apr 16, 2006, at 11:09 AM, Kevin Ollivier wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> BTW, you might want to consider having a separate project
>>>> file that
>>>> >> generates the cross-platform webcore sources as a static library
>>>> >> (say, a
>>>> >> "WebCoreBase" project file), and then have the Win32, etc.
>>>> projects
>>>> >> statically link in that library and only build the files
>>>> specific
>>>> >> to their
>>>> >> port/platform (and of course, depend on WebCoreBase). Actually,
>>>> >> I've pretty
>>>> >> much already set up the Bakefile projects this way, so that you
>>>> >> can see what
>>>> >> I mean when I submit the patch. :-) This way there wouldn't
>>>> be any
>>>> >> redundancy among projects in terms of maintaining the cross-
>>>> platform
>>>> >> sources, and each port will only ever have to worry about
>>>> >> updating/maintaining its own specific files.
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> webkit-dev mailing list
>>>> >> webkit-dev at opendarwin.org
>>>> >> http://www.opendarwin.org/mailman/listinfo/webkit-dev
>>>> >>
>>>> >>
>>>> >>
>>>>
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at opendarwin.org
>>>> http://www.opendarwin.org/mailman/listinfo/webkit-dev
>>>>
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at opendarwin.org
>>>> http://www.opendarwin.org/mailman/listinfo/webkit-dev
>>>
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at opendarwin.org
>>> http://www.opendarwin.org/mailman/listinfo/webkit-dev
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at opendarwin.org
>> http://www.opendarwin.org/mailman/listinfo/webkit-dev
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at opendarwin.org
> http://www.opendarwin.org/mailman/listinfo/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20060422/29bf565c/attachment.html
More information about the webkit-dev
mailing list