[webkit-dev] Build system for ports

Mike Emmel mike.emmel at gmail.com
Sat Apr 22 10:21:45 PDT 2006 

On 4/22/06, Justin Haygood <jhaygood at spsu.edu> 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 < 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
>
>
>

More information about the webkit-dev mailing list