Re: [E-devel] Use of the 'Requires.private' field in pkg-config files

2008-02-24 Thread The Rasterman
On Wed, 6 Feb 2008 18:47:28 +0100 Albin Tonnerre [EMAIL PROTECTED]
babbled:

indeed. a very good point. but i'd rather wait on this for a while longer until
pkgconfig 0.22 is just about the only version around (or newer) :)

 Hello,
 
 I'd like to suggest that we use the new (as of pkg-config 0.22)
 'Requires.private' flag in the .pc files instead of the current 'Requires'
 flag.
 
 'Requires.private' is a field that basically has the same role as 'Requires'.
 However, the dependencies listed in this field are not used when
 `pkg-config --libs foobar' is called (only when dynamic linking is done, ie no
 --static is specified).
 This prevents unneeded recursive linking of the dependencies, like this is
 currently the case (eg, everything linked against ecore-file with CURL support
 enabled is also linked against curl, which is a maintenance hell and a
 complete nonsense, and this is one example out of many).
 That means that in our case, Requires.private field can replace Requires
 virtually everywhere if the dependencies have no undefined symbols and if they
 don't specify anything else than -l/-L flags.
 
 As a quick example of what the benefit would be, I rebuilt the EFL, E, etk and
 ewl using Requires.private instead of Requires in their pkg-config files, and
 ran objdump -p $foo | grep NEEDED on every {module,shared library,binary}
 before and after the change. The results can be found at
 http://people.dunnewind.net/lutin/files/efl_links--.diff
 
 The obvious drawback, of course, is that it would break build on every install
 where pkg-config 0.22 is not available, which is quite unpleasant, given that
 it's only 8-month old. I'm sending this mail for the record, though :)
 
 Cheers,
 -- 
 Albin Tonnerre, aka Lutin
 


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Use of the 'Requires.private' field in pkg-config files

2008-02-06 Thread Albin Tonnerre
Hello,

I'd like to suggest that we use the new (as of pkg-config 0.22)
'Requires.private' flag in the .pc files instead of the current 'Requires' flag.

'Requires.private' is a field that basically has the same role as 'Requires'.
However, the dependencies listed in this field are not used when
`pkg-config --libs foobar' is called (only when dynamic linking is done, ie no
--static is specified).
This prevents unneeded recursive linking of the dependencies, like this is
currently the case (eg, everything linked against ecore-file with CURL support
enabled is also linked against curl, which is a maintenance hell and a complete
nonsense, and this is one example out of many).
That means that in our case, Requires.private field can replace Requires
virtually everywhere if the dependencies have no undefined symbols and if they
don't specify anything else than -l/-L flags.

As a quick example of what the benefit would be, I rebuilt the EFL, E, etk and
ewl using Requires.private instead of Requires in their pkg-config files, and
ran objdump -p $foo | grep NEEDED on every {module,shared library,binary} before
and after the change. The results can be found at
http://people.dunnewind.net/lutin/files/efl_links--.diff

The obvious drawback, of course, is that it would break build on every install
where pkg-config 0.22 is not available, which is quite unpleasant, given that
it's only 8-month old. I'm sending this mail for the record, though :)

Cheers,
-- 
Albin Tonnerre, aka Lutin


signature.asc
Description: Digital signature
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel