[webkit-dev] Build system for ports

Sat Apr 22 09:11:21 PDT 2006

FIles to be compiled to be managed bny Bakefile, and custom VS2005 build
settings to be done manually

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20060422/bf71098b/attachment.html