[Gtk-sharp-list] [Patch, etc] minimal pkgconfig support

[Charles Iliya Krempeaux]

Hello,

On Wed, 2003-03-26 at 21:30, Mike Kestner wrote:
> On Tue, 2003-03-25 at 23:53, Charles Iliya Krempeaux wrote:
> 
> Hi Charles,
> 
> > There was one naming convention I used, because of a bit of
> > naming conflict.  For each of the assemblies, there is a
> > pkgconfig file.  Specifically...
> > 
> >     Art#     ->  art-sharp.pc
> >     Atk#     ->  atk-sharp.pc
> 
> Oy, that's a lot of pc's.  I'm not sure we need to provide granularity
> below Gtk, so we can combine glib, pango, atk, gdk, and gtk.  Maybe we
> should base the granularity on the configure checks?

I disagree.  I explain why later in this message.


> > However, this leave us with a problem.  What do we call the
> > entire package as a whole?  Following what we has been done
> > with the Mono Hand Book (a.k.a. the MonkeyGuide), I've called
> > the entire package gnome.net and made the gapi .pc file:
> > 
> >     gnome.net-gapi.pc
> 
> gapi.pc should be fine.  We are installing a file in bin called gapi.pl,
> so if there are namespacing issues they will already be hitting us
> elsewhere.

OK... I'll do that.


> > Now, having said all of that, I want to make it so that doing a:
> > 
> >     pkg-config --libs gdk-sharp
> > 
> > Returns the assemblies you need.  But there are some problems
> > with this that need to be worked out first.
> > 
> > (Most of these are related to the fact that Mono, Portable.NET, and
> > MS's csc all use different switches to do the same thing.  And that
> > Mono likes to put whitespace before the -L switch.  But I'll deal
> > with this in a future Patch.)
> 
> mcs and csc should be able to use identical switches.  I think mcs
> emulates all the csc switches now.

I don't think Portable.NET's cscc handles those switches though.
(I don't want Portable.NET to be left out.)

(We could always modify pkgconfig to maybe check an environment
variable, and then output the switches in a format that cscc
understands.)


> > So... is it OK to commit this.  (Or should I rename anything?  Etc?)
> 
> We need to rethink the granularity a bit.  Anyone else have any opinions
> on this?

I do.

The reason I created so many different .pc files, is that so the user
could bind their .exe (or .dll) file to a minimum set of .dll's.

So, for example, if I wanted to only use GnomeVFS#, then I could
do a:

    pkg-config --libs gnomevfs-sharp

And this would any bring in the .dll's that I need to use for
GnomeVFS#.  (It wouldn't bring in gnome-sharp.dll.
It wouldn't bring in pango-sharp.dll.  Etc.)

So... basically having this amount of .pc files is
to make it so only a minimum set of .dll files
are binded to your .exe (of .dll) file.


> Are we breaking ground and setting precedents here that the
> rest of the mono project should be consulted about?

Yes.  Before I did this, I asked on #mono on what the convention
was for pkgconfig.  Specifically, I was trying to find out if
people were using the --libs option, the --cflags option, or
something else, to bring in assemblies.

>From what I heard (from #mono) there was NO convention yet.  So
I arbitrarily choose to use --libs.  The people who I was talking
to on #mono were OK with this.  (Since it made more sense than
the --cflags option.)


> Since pkg-config is
> primarily targetted at C projects, maybe we need to be considering
> cooking a different solution that works better for the C# realm?

IMO, I think we need our own pkgconfig flag.  Maybe an --assemblies
flag.  And then we'd do stuff like:

    pkg-config --assemblies gnome-sharp

IMO, I don't think we should ditch pkg-config.  pkg-config already
plays a large role with the auto* tools.

Adding a new flag to it (and a new type of entry in the
.pc files, for assemblies) should probably be sufficient.

What do you think?


See ya

-- 
     Charles Iliya Krempeaux, BSc
     charles@reptile.ca

________________________________________________________________________
 Reptile Consulting & Services    604-REPTILE    http://www.reptile.ca/