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 <[EMAIL PROTECTED]> 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,
On 4/18/06, Kevin Ollivier <[EMAIL PROTECTED] > 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,
On 4/16/06, Kevin Ollivier < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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
>> [email protected]
>> http://www.opendarwin.org/mailman/listinfo/webkit-dev
>>
>>
>>
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list
_______________________________________________ webkit-dev mailing list
_______________________________________________ webkit-dev mailing list
|
