[webkit-dev] Build system for ports

Sat Apr 22 00:29:30 PDT 2006

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20060422/fdcad2de/attachment.html