On 4/22/06, Justin Haygood <[EMAIL PROTECTED]> wrote: > FIles to be compiled to be managed bny Bakefile, and custom VS2005 build > settings to be done manually >
So you want it to patch the VS2005 build file if it exists ? I think this leads to problems depending on how they differ. I think it would only work for parts of the build file say custom settings so it should overlay existing settings on its generated file. See http://www.pms.ifi.lmu.de/forschung/xml/xml-toolkit.html > > On 4/22/06, Kevin Ollivier < [EMAIL PROTECTED]> 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 <[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, > > > > > > > > > > > > Kevin > > > > > > > > > > > > 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, > > > > > > > > > > > > > > > > Kevin > > > > > > > > > > > > > > > > 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 > > > > [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 > > [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 [email protected] http://www.opendarwin.org/mailman/listinfo/webkit-dev
