[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

dsp generator (was: Final year project)

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-10-23 03:18:02 CEST

On Tue, Oct 22, 2002 at 11:45:03PM +0200, Branko Cibej wrote:
>...
> >P/Invoke only works on dynamic libraries, while the SVN API on Win32
> >is still just a set of static libraries. I don't know what the
> >timeframe for changing it to DLL's are(anyone?),
>
> It's on my list for Beta. I have to write a .dsp generator first,
> because I definitely don't propose to edit and fix all the project files.

Right. Part of my hope for a dsp generator is that it will be easier to
maintain the darned things. We have a lot of libraries, so fixing flags and
adding features and whatnot is a serious pain.

I've moved some of the stuff out of the MakefileGenerator class, and have an
idea to *really* kick some stuff out of there. Hopefully, that will reduce
the code in the MakefileGenerator to simply be "output". Today, it is a mix
of derive/find/analyze *and* output.

Basically, my next modification is to add a generalized dependency DAG to
the Generator base class. Then, I'd throw in all the includes, C files,
object files, libraries, etc in there. The generator subclasses can then use
the general dep graph in whatever fashion is appropriate for their output.

The rationale here is that I'm finding the current code a bit confining.
Each of the swig "targets" actually generates a multitude of dependency
lines. In essence, what is a single target today will (when swig stuff is
added) will become multiple targets (one per language). The current
structure doesn't provide for that very well.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 23 03:18:20 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.