On Wed, Feb 1, 2017 at 12:42 PM, Stefan Schmidt <[email protected]> wrote:
> Hello.
>
> On 01/02/17 15:31, Gustavo Sverzut Barbieri wrote:
>> On Wed, Feb 1, 2017 at 11:47 AM, Stefan Schmidt <[email protected]>
>> wrote:
>>> Hello.
>>>
>>> On 01/02/17 14:39, Gustavo Sverzut Barbieri wrote:
>>>> On Wed, Feb 1, 2017 at 11:24 AM, Stefan Schmidt
>>>> <[email protected]> wrote:
>>>>> stefan pushed a commit to branch master.
>>>>>
>>>>> http://git.enlightenment.org/core/efl.git/commit/?id=592f356fe5cc64ac6e790d2014edfd11dcfc17a5
>>>>>
>>>>> commit 592f356fe5cc64ac6e790d2014edfd11dcfc17a5
>>>>> Author: Stefan Schmidt <[email protected]>
>>>>> Date: Wed Feb 1 14:22:11 2017 +0100
>>>>>
>>>>> cmake: remove dependency on libjpeg in eet as it is handled in common
>>>>> ---
>>>>> src/lib/eet/CMakeLists.txt | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/src/lib/eet/CMakeLists.txt b/src/lib/eet/CMakeLists.txt
>>>>> index 813f293..76b71a4 100644
>>>>> --- a/src/lib/eet/CMakeLists.txt
>>>>> +++ b/src/lib/eet/CMakeLists.txt
>>>>> @@ -2,7 +2,7 @@ set(DESCRIPTION "Library for speedy data storage,
>>>>> retrieval, and compression")
>>>>>
>>>>> set(PKG_CONFIG_REQUIRES_PRIVATE
>>>>> zlib>=1.2.3
>>>>> - libjpeg
>>>>> + #libjpeg is hard to find. there is a cmake module that does find it.
>>>>> and thats checked in common.cmake
>>>>> )
>>>>
>>>> You got this wrong, this is not just to check, it's to use. Now you'll
>>>> have cmake build of eet with undefined symbols.
>>>>
>>>> This is also used to generate .pc files, see my other email.
>>>
>>> Fair enough. I actually try to understand the cmake stuff at all right
>>> now and trying it out. Pretty likely my fixes are off here.
>>>
>>> And indeed I run into missing symbols now (emile not eet in this case)
>>
>> ok, fixed in master, now we process LIBRARIES and look for "find-XXX",
>> in that case replace with XXX_LIBRARIES and also add include
>> directories.
>
> Thanks. After your change I can now fully build what we have covered
> with cmake.
>
>> Now I'm wondering if we remove special PKG_CONFIG_REQUIRES variable
>> and use LIBRARIES with some "pkgconfig-XXX"... what do you think?
>
> Not sure really if I have an opinion on that just now. I will need to
> read through all the cmake stuff first. Its the first project I would
> use it with (well besides having build some, but really nothing besides
> calling cmake). It will take me some time to grok this. :)
you can/should ping me or Marcel.
Our idea is to create a standard, a path to be followed by all others
so we make it as automatic as possible.
Traditional usage of CMake is like automake, you use the basics and
specify it all: create a target, set properties... which in our case
can be avoided by using functions/macros to benefit from our file
structure and all libraries trying to follow a pattern of names,
version, installation and so on.
This is where I believe automake is much worse, because we can add m4
macros for autoconf (like many we have in m4/*), but we can't add to
automake, then we replicate a huge configuration for each target and
sometimes we end with inconsistent behavior due copy&paste not being
updated as should.
A second benefit of cmake is to have control of build results, we can
mimic ${prefix}/XXX layout inside build/, this allows eina_prefix to
work and we can remove the cumbersome EFL_RUN_IN_TREE hacks.
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
