- From: Reitzel, Charlie <CReitzel@arrakisplanet.com>
- Date: Wed, 23 May 2001 13:23:16 -0400
- To: "'Terry Teague'" <teague@mailandnews.com>
- Cc: html-tidy@w3.org
Hi Terry, I'm copying the list to keep everyone in the loop. Source tree: Your source tree looks almost identical to my directories I used to build at home, plus autoconf stuff (which looks much like expat). So I think it is a go. Can you go ahead and load it up? Maybe a post about autoconf/source tree to the design forum on the project would let everyone follow what going on. Bug loading: Looks like we're going to have to slog through the Perfect Tracker forms. How about we split it up? If you load your pages, I'll load the Pending stuff. Can we get a volunteer to take one of Terry's pages (there's two because of the size)? My primary motive here is the test plan. We'll have to think about a test bed at some point, but a bug list is a good start. Charlie P.S. About Project permissions, I believe all project members have commit rights to CVS and the ability to load documents and post to all forums (fora?). If this isn't true, please let me or Terry know and we'll figure out how to open it up. Please allow for a bit of Source Forge learning curve... -----Original Message----- From: Terry Teague [mailto:teague@mailandnews.com] Sent: Wednesday, May 23, 2001 3:58 AM To: Reitzel, Charlie Subject: RE: FW: SourceForge Project Approved Dear Charlie, >You're in. I gave you the kitchen sink for permissions. Without giving it >much thought, I have been setting up regular developers w/ out too much >permissions, yet, but am including everyone on all email lists (bugs, etc.). >I'm guessing we'll divy up list moderation / release engineering / >documentation editorial duties between us all. > >In general, it's probably better to open things up than keep things locked >down. In particular, I'd rather keep the forums un-moderated for project >members. I'm not sure how to do that yet. Sounds good. >Let's put our (collective) heads together about autoconf. I want to get >this in up front because I think it will, in part, determine our CVS >directory structure. Just thinking out loud here, but I believe autoconf >could be used for a MacOS build of the library itself. We can create >separate subprojects for platform and/or environment specific integrations >(e.g. Apple Events, COM, MS Visual Studio, etc.). I had a quick look at a bunch of open source projects for multiple platforms that are on my hard disk. They all use slightly different styles, and a couple use autoconf. But it seems like the typical source tree looks like : project/ configure.guess configure.sub doc/ examples/ src/ tests/ platform1/ platform2/ ... platformn/ README ... etc and some top level directories have platform specific subdirectories, perhaps complete with their own configure, Makefile, platform-specific build scripts etc. For Mac OS X, autoconf would work - I have configure.guess and configure.sub files specific to Darwin (the Core OS used in Mac OS X) that come with Darwin (I haven't looked at them yet). For pre-Mac OS X, typically open source that has been ported to Mac OS, have their own install scripts and build scripts (typically for MPW, a standard development environment for Mac OS, that has features similar to those in UN*X), or Metrowerks CodeWarrior project files (CW is a very popular GUI based development environment for Mac OS). Based on the above (experience) and what I do for Tidy on Mac OS, I would probably propose something like the following for the Tidy CVS repository : tidy/ configure.guess configure.sub htmldoc/ examples/ include/ lib/ src/ tests/ win32/ macos/ gcc/ ... platformn/ README and I would put the current html.h platform.h into the "include/" directory, with overrides in the platform specific sub-directories. Similarly for the ".c" files into the "src/" directory. Maybe sample "config" files (if the Tidy library will support them directly) go into the "examples/" directory. It doesn't seem (to me) too hard to change the CVS hierarchies later, if we change our minds. I don't know if this is a standard feature of CVS or not, but Apple provides some CVS wrapper scripts which are added to CVSROOT for the purpose of having CVS automatically handle special directories that appear to the user as a single unit ("bundle"), by tar/untar'ing the contents, handling binary files appropriately. If this is not a standard feature of CVS, I might want to add these scripts to CVSROOT. I will do a bit more investigation. >I'm wondering if we couldn't write a funky Perl script to load your bug >list into Perfect Tracker. Do you have this data in tabular form anywhere? No such luck. I basically copied/pasted from the tidy mailing list Emails and source code to my HTML layout program. I lost both the EMails and the source HTML in my hard disk crash - fortunately I was able to suck down the web site. If you want to write a Perl script to massage my HTML, be my guest. I figured I would just copy/paste the bugs manually. I have yet to have a look at Perfect Tracker. Regards, Terry
Received on Wednesday, 23 May 2001 13:22:56 UTC