dsp generator (was: Final year project)

[Greg Stein <gs...@lyra.org>]

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

Re: dsp generator (was: Final year project)

[Branko Čibej <br...@xbc.nu>]

Greg Stein wrote:

>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.
>
Saw that. I'd started on a similar transformation, because without it 
there'd be a lot of useless code duplication. Thanks!

>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.
>  
>
That should make generating more complex .dsp files easier, too. Let me 
know when you think it's fairly stable again.

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org