[MonoDevelop] Autotools plugin.

[Scott Ellington]

Hi,

I have committed functionality that creates a pc file for every library
in the solution.  This is enabled by default but can be disabled via the
solution options.  

So, say you have a project 'MyLibrary' in solution 'MySolution', a
pkg-config module will be installed with the name
'MySolution.MyLibrary'.

One issue I see is an issue with the guidelines for deploying unstable
libraries: 

http://www.mono-project.com/Guidelines:Application_Deployment#Libraries_with_Unstable_APIs

Say I have one library depending on another unstable library, I can use
'pkg-config --libs MyLibrary' to get references to it and to all of it's
dependencies recursively.  Then I use the 'Libraries' variable to copy
the actual dlls into my working directory.  However, this will only give
me the dlls I need for the top-level library not the dependencies.  So I
would need to go in to the pc file and manually check the other packages
for the Libraries variable.  I would think the Libraries variable should
behave like --libs.

Any thoughts?

Scott


On Mon, 2006-07-10 at 17:07 -0400, Miguel de Icaza wrote:
> Hello,
> 
> > I think a better way to handle this type of situation would be to permit
> > the creation of pc files for nested solutions. 
> > 
> > Say you have solution 'mylib'.  This solution contains all the non-gui
> > projects (dlls).  A pc file would be created for these libs.  Then,
> > within this solution, you could create another solution called
> > 'mylib-gui'.  This would have all the gui libs, and another pc file
> > would be created for this solution with 'mylib' in the 'Requires'
> > variable.
> > 
> > This would give you some granularity without unneccessarily polluting
> > pkgconfig with a pc for each individual dll.
> 
> This seems more complicated than just generating a new .pc file for each
> DLL.   
> 
> What I would like to aim for is for good sensible defaults, something
> that makes things work out of the box.  Our Unix development environment
> is already too complicated as it is.
> 
> Miguel.