| 1 |
On Monday 30 April 2012 14:27:29 Samuli Suominen wrote: |
| 2 |
> +1 for creating the virtual and migrating the tree to use |
| 3 |
> virtual/pkgconfig. although, on the otherhand, you could just use |
| 4 |
> package.provided for thesetype of unsupported experiments (like i'm |
| 5 |
> doing with pkgconfig-openbsd) |
| 6 |
|
| 7 |
ok, with no one against the virtual, i'll implement it |
| 8 |
|
| 9 |
> [1] pkgconf is not compatible as per Comment #5 of bug 413849. needs to |
| 10 |
> follow same version scheme as f.d.o's pkg-config. |
| 11 |
|
| 12 |
there seems to be miscommunication there. it's compatible. |
| 13 |
|
| 14 |
> [2] pkg-config-lite should be punted from tree as per bug 414101, |
| 15 |
> unnecessarily bundling glib code. |
| 16 |
|
| 17 |
not getting punted. what little glib code it bundles (and it really is quite |
| 18 |
little) is hand extracted. it doesn't just drop the glib tarball in there. |
| 19 |
|
| 20 |
would be nice if the eglib replacement (that bluez used to use) grew legs ... |
| 21 |
then we could even use that. |
| 22 |
|
| 23 |
otherwise, much of the glib funcs are brain dead simple and can be replaced |
| 24 |
with #defines. g_free() for example is a waste of space. |
| 25 |
|
| 26 |
> there is no real problem with using |
| 27 |
> external glib. not liking it doesn't make it a problem. it's perfectly |
| 28 |
> bootstrappable and the bootstrapping is documented (plus ebuilds does |
| 29 |
> this for users so it's nothing you should even be thinking about...) |
| 30 |
|
| 31 |
glib-2 is not an acceptable hard requirement. its hard requirement on full |
| 32 |
locale/multibyte support is a non-starter. |
| 33 |
|
| 34 |
> [3] pkgconfig-openbsd is incompatible in many ways, for example, doesn't |
| 35 |
> pass -pthread/-lpthread properly and breaks on -Wl,--as-needed systems. |
| 36 |
|
| 37 |
i have no interest in that |
| 38 |
-mike |
Archives