On sam, nov 26, 2005, Loic Minier wrote: > (we had this discussion on IRC already) More bits, the new information here is that people involved in pkg-config think that using headers of another lib in your headers means you have a public dep on this other lib, and that will result in an ELF dep. It also clarifies that the improvement is because of the removal of the static flags which caused dynamic deps, and won't improve gtk-ish/gnome-ish libs. 21:55 < lool> vorlon: if you have two minutes, could you please send a word to ? 21:57 < Q_> lool: Still waiting for a fix so I can build gtk-sharp2. 21:58 < lool> Q_: well, I'm still waiting for a consensus to be reached, I think the stronger opinion was to add only -Is from private fields 21:58 < lool> but this is all too borderline for me to take the decision, one way or the other 22:00 < Q_> Mithrandir: Around? 22:01 < lool> Q_: BTW, I filed #340904 to track the story 22:02 < vorlon> lool: what word are you looking for? :) 22:03 < lool> vorlon: the kind of word carrying final-person opinion (eg where I don't relay opinions from third parties :) 22:04 < lool> this is really a pkg-config design question for me, and the technical implementation is not the problem, so I'd rather have you or Mithrandir or who ever feels he knows what is correct express himself there, than me 22:05 < vorlon> lool: well, Mithrandir and I seem to disagree here on what the correct design is, and one of is is pkg-config upstream whereas the other is not. :) 22:06 < Q_> lool: And nothing happened to it yet. 22:06 < lool> vorlon: exactly, and since I'm not strongly convinced one way or the other, I can't represent either party in the discussion O:-) 22:08 < vorlon> lool: well, I don't see much point in trying to argue the pkg-config design details in a bug report against *vte*: that's not fair to the vte maintainers, and it's not a very effective means of getting pkg-config changes made. I don't feel strongly enough about this corner case today to argue it at *all*, really. 22:10 < lool> vorlon: well, I wanted your take on the situation to vte's upstream which is now victim of the change too, I can try to explain the situation myself to vte's upstream, but I will be short of arguments what ever camp vte's upstream picks 22:10 * lool bravely goes telling vte maintainer that we've pulled them in a mid-term problem 22:12 < Mithrandir> Q_: yes 22:13 < vorlon> lool: I don't think vte upstream is going to pick the "I'll let my software continue to be broken" camp 22:14 < lool> exactly 22:14 < Q_> Mithrandir: So, did you have some time to think about the problem, and the best way to solve it? 22:14 < dilinger> i wish i could admin some AIX machines 22:15 < dilinger> i bet it would cause me to get a lot less frustrated when i'm faced w/ crap like redhat and suse 22:15 < Mithrandir> Q_: oh, the requires.private stuff? 22:16 < Q_> Mithrandir: Yes, the -I 22:17 < Mithrandir> 02:39 < jamesh> Mithrandir: about your pkg-config question: no. If a package is a private dependency, then its interface shouldn't be exposed at all. 22:17 < Mithrandir> 02:39 < jamesh> Mithrandir: so the -I flags shouldn't be included 22:18 < Q_> You mean we should try to convince jamesh? 22:18 < Mithrandir> I'm somewhat inclined to agree with jamesh, but neuro had some comments which went in the other direction. I think I'll have to sit down and look at what can go wrong in the different situations. 22:18 < Mithrandir> yes, if you convince jamesh, I'm ok with it. He knows a bloody lot about how pkg-config works, is supposed to work and why it works that way. 22:19 * lool wishes for a clearer definition of the goal of the requires.private header 22:21 < vorlon> lool: well, this opinion from jamesh is consistent with treating glib as a *public* dependency of gtk just because software can cheat and use glib API calls directly when only including gtk. :P 22:23 < Mithrandir> vorlon: yes, but what if glib was a private dependency of gtk? Would it be ok to expose, say, gchar*? 22:24 < Mithrandir> (or better, gchar, since a pointer is always ok) 22:25 < vorlon> Mithrandir: if gchar is used in the gtk headers, yes. :) 22:25 < Q_> Mithrandir: A pointer isn't any better. 22:25 < vorlon> Q_: it's legal to have pointers in C that you don't have enough information to be able to dereference. 22:26 < Mithrandir> Q_: sure it is, as long as you don't expose the typedef. 22:26 < Mithrandir> so you can't dereference it, as vorlon says. 22:27 < Q_> vorlon: But you still need to say that it's a type. 22:28 < Mithrandir> Q_: a struct would be a better example and then you can just say struct foo; and use struct foo* without any trouble. 22:28 < Q_> so something like "struct foo *bar;" works, "struct foo bar;" doesn't. 22:29 < Q_> But at that point you don't even need the include in the first place. 22:30 < lool> vorlon: if you look at private/public deps in this way, then my feeling is that this clarifies deps for static linking, but won't help reducing dynamic deps 22:31 < vorlon> lool: ? 22:31 < Mithrandir> lool: and we want to reduce dynamic deps. Possibly not perfectly (stuff linked to gtk will still link to glib, since it's an actual public dependency), but better than today. 22:31 < vorlon> lool: which way? 22:32 < lool> vorlon: in the way of jamesh proposing to treat such interfaces as public deps 22:32 < lool> anyone minds if I copy paste this log to the bug? 22:33 < Mithrandir> lool: feel free 22:33 < lool> Mithrandir: true, it's just sad this helps so little in the case of gtk-ish libs 22:35 < Q_> Anyway, I think the point was if that gchar is part of gtk headers, and gchar changes in such a way that it breaks gtk, and so also things linked to gtk, that both got an api change, and both should do an soname change. 22:35 < vorlon> lool: it's less than ideal, but there are still *some* lib savings. 22:36 < Mithrandir> I would like to accomodate the gnome/gtk model of handling headers, though. 22:36 < Q_> And that might not be something the gnome people would like to do? 22:37 < lool> Q_: well they included vorlon's patch quite rapidly 22:37 < lool> Q_: I suppose they will use any pkg-config coolness you explain them to use 22:38 < Q_> lool: I think they don't want to and change all their sonames because something in glib changed. 22:38 < Q_> s/to/to go/ -- Loïc Minier