W3C home > Mailing lists > Public > html-tidy@w3.org > April to June 2001

RE: FW: SourceForge Project Approved

From: Reitzel, Charlie <CReitzel@arrakisplanet.com>
Date: Wed, 23 May 2001 13:23:16 -0400
Message-ID: <B5C79DDBC655D311B6BD0008C7E64D76013C1545@exchange.arrakisplanet.com>
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

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.


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

-----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,
>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 :


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 :


and I would put the current


into the "include/" directory, with overrides in the platform specific

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

>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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:38:50 UTC