Re: [E-devel] Introduction of jefl
On Thu, 23 Apr 2020 22:34:04 +0930 Simon Lees said: > > > On 4/23/20 8:24 PM, Carsten Haitzler (The Rasterman) wrote: > > On Thu, 23 Apr 2020 12:37:53 +0930 Simon Lees said: > > > >> > >> > >> On 4/22/20 2:46 AM, Carsten Haitzler (The Rasterman) wrote: > >>> > >>> dependencies outside of efl > >>> continues to be friction to the point where if i could go back in time, > >>> i'd never link to deps ever again. > >> > >> Having separate bindings doesn't really make this worse. As a handy > >> hint, if your on a distro that ships efl, even an old version installing > >> then uninstalling efl-devel will leave pretty much all the deps > >> installed on your machine (you will also have to uninstall efl if you > >> don't want the old version.) > > > > deps i mean -lblah - linking at link time as opposed to dlopen > > Thats meson's problem :-) , if you tried to dlopen everything you'd just no - it's a "i can;'t compile efl - i need docs for my distro because i don't know how to install dev/devel files - it's too hard". having to write a special list of "apt/yum/dnf/pacman/whatever install x y z" is not sane as every distro is different and it's a moving target. so moving all deps out to at-rumtime has a few benefits: 1. less commonly used deps don't even need an install if the user doesn't know or care. 2. it allows for a runtime "feature missing because lib y cant be loaded" which turns into a nice path we could put off to a tool to help install a dep 3. it saves dirty pages and linking time at startup for a process for deps that may never be used 4. things compile without someone first having to beat their head on "install 30 packages to compile efl". you, as a packager might not care about some of these, but as someone who sees the problems decade after decade for others ... and the bonuses too above... i'd do things differently now after learning that. that or i'd pull more dependencies into the efl tree itself and have them compiled in... > end up with stuff not working because distro's didn't realize they > should ship that library, this is why autodetect feature in autotools / > meson was bad. > > I don't think there are really good solutions to these problems, just > ones that are slightly less bad or slightly different to others > > -- > > Simon Lees (Simotek)http://simotek.net > > Emergency Update Team keybase.io/simotek > SUSE Linux Adelaide Australia, UTC+10:30 > GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL 1.24 first abi checker results (beta2)
I can confirm that these are not legacy types and further have never been shipped in a stable release (as of pre-1.24). On Thu, Apr 23, 2020 at 6:34 AM Ali Al-Zyoud wrote: > Hello, > > For Efl_Canvas_Text and Efl_Text_Cursor_Cursor, I do not think they are > supposed to be used anyway especially in a Legacy application (also they > were beta anyway), but the defines leaked out from headers. > > Thanks > Ali Alzyod > > On Thu, Apr 23, 2020 at 12:16 PM Jean Rene Dawin < > jda...@math.uni-bielefeld.de> wrote: > > > Jean Rene Dawin wrote on Wed 22/04/20 19:19: > > > Stefan Schmidt wrote on Wed 22/04/20 14:05: > > > > Hello Jean Rene. > > > > > > > > On 22.04.20 08:27, Jean Rene Dawin wrote: > > > > > Stefan Schmidt wrote on Wed 15/04/20 15:48: > > > > > > Hello. > > > > > > > > > > > If my code has this: > > > > > > > > > > Efl_Canvas_Text *bla; > > > > > > > > > > it compiles well with 1.23.3 but 1.24 gives > > > > > > > > > > unknown type name 'Efl_Canvas_Text' > > > > > > > > > > > > > Thanks a lot for bringing this to our attention. Sorry for missing it > > in the > > > > first place. After some discussion with Marcel Ali came up with a > > patch that > > > > should fix the problem for you. > > > > > > > > This should fix your problem: > > > > https://phab.enlightenment.org/D11744 > > > > > > > > I am going to push this now. Please let us know if it is working > > correctly > > > > afterwards for you. > > > > > > > > regards > > > > Stefan Schmidt > > > > > > Thanks. Honestly I don't have code that is affected right now. > > > I just was curious if the warnings of the ABI checker were all harmless > > and did a test > > > with the code above. > > > > > > Regards, > > > Jean Rene > > > > Ok, with f619a2fbad2dcc81085f14cedaea4fc0df8f2837 Efl_Canvas_Text is > > fixed. > > > > I'm still not sure if a program is supposed to use these types directly > > in the first place. > > > > Similar issues occur with these types: > >Efl_Canvas_Vg_Container > >Efl_Canvas_Vg_Node > >Efl_Text_Cursor_Cursor > > > > Regards, > > Jean Rene > > > > > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Introduction of jefl
On 4/23/20 8:24 PM, Carsten Haitzler (The Rasterman) wrote: > On Thu, 23 Apr 2020 12:37:53 +0930 Simon Lees said: > >> >> >> On 4/22/20 2:46 AM, Carsten Haitzler (The Rasterman) wrote: >>> >>> dependencies outside of efl >>> continues to be friction to the point where if i could go back in time, i'd >>> never link to deps ever again. >> >> Having separate bindings doesn't really make this worse. As a handy >> hint, if your on a distro that ships efl, even an old version installing >> then uninstalling efl-devel will leave pretty much all the deps >> installed on your machine (you will also have to uninstall efl if you >> don't want the old version.) > > deps i mean -lblah - linking at link time as opposed to dlopen Thats meson's problem :-) , if you tried to dlopen everything you'd just end up with stuff not working because distro's didn't realize they should ship that library, this is why autodetect feature in autotools / meson was bad. I don't think there are really good solutions to these problems, just ones that are slightly less bad or slightly different to others -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Introduction of jefl
On Thu, 23 Apr 2020 12:37:53 +0930 Simon Lees said: > > > On 4/22/20 2:46 AM, Carsten Haitzler (The Rasterman) wrote: > > > > dependencies outside of efl > > continues to be friction to the point where if i could go back in time, i'd > > never link to deps ever again. > > Having separate bindings doesn't really make this worse. As a handy > hint, if your on a distro that ships efl, even an old version installing > then uninstalling efl-devel will leave pretty much all the deps > installed on your machine (you will also have to uninstall efl if you > don't want the old version.) deps i mean -lblah - linking at link time as opposed to dlopen > -- > > Simon Lees (Simotek)http://simotek.net > > Emergency Update Team keybase.io/simotek > SUSE Linux Adelaide Australia, UTC+10:30 > GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL 1.24 first abi checker results (beta2)
Hello, For Efl_Canvas_Text and Efl_Text_Cursor_Cursor, I do not think they are supposed to be used anyway especially in a Legacy application (also they were beta anyway), but the defines leaked out from headers. Thanks Ali Alzyod On Thu, Apr 23, 2020 at 12:16 PM Jean Rene Dawin < jda...@math.uni-bielefeld.de> wrote: > Jean Rene Dawin wrote on Wed 22/04/20 19:19: > > Stefan Schmidt wrote on Wed 22/04/20 14:05: > > > Hello Jean Rene. > > > > > > On 22.04.20 08:27, Jean Rene Dawin wrote: > > > > Stefan Schmidt wrote on Wed 15/04/20 15:48: > > > > > Hello. > > > > > > > > > If my code has this: > > > > > > > > Efl_Canvas_Text *bla; > > > > > > > > it compiles well with 1.23.3 but 1.24 gives > > > > > > > > unknown type name 'Efl_Canvas_Text' > > > > > > > > > > Thanks a lot for bringing this to our attention. Sorry for missing it > in the > > > first place. After some discussion with Marcel Ali came up with a > patch that > > > should fix the problem for you. > > > > > > This should fix your problem: > > > https://phab.enlightenment.org/D11744 > > > > > > I am going to push this now. Please let us know if it is working > correctly > > > afterwards for you. > > > > > > regards > > > Stefan Schmidt > > > > Thanks. Honestly I don't have code that is affected right now. > > I just was curious if the warnings of the ABI checker were all harmless > and did a test > > with the code above. > > > > Regards, > > Jean Rene > > Ok, with f619a2fbad2dcc81085f14cedaea4fc0df8f2837 Efl_Canvas_Text is > fixed. > > I'm still not sure if a program is supposed to use these types directly > in the first place. > > Similar issues occur with these types: >Efl_Canvas_Vg_Container >Efl_Canvas_Vg_Node >Efl_Text_Cursor_Cursor > > Regards, > Jean Rene > > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL 1.24 first abi checker results (beta2)
Jean Rene Dawin wrote on Wed 22/04/20 19:19: > Stefan Schmidt wrote on Wed 22/04/20 14:05: > > Hello Jean Rene. > > > > On 22.04.20 08:27, Jean Rene Dawin wrote: > > > Stefan Schmidt wrote on Wed 15/04/20 15:48: > > > > Hello. > > > > > > > If my code has this: > > > > > > Efl_Canvas_Text *bla; > > > > > > it compiles well with 1.23.3 but 1.24 gives > > > > > > unknown type name 'Efl_Canvas_Text' > > > > > > > Thanks a lot for bringing this to our attention. Sorry for missing it in the > > first place. After some discussion with Marcel Ali came up with a patch that > > should fix the problem for you. > > > > This should fix your problem: > > https://phab.enlightenment.org/D11744 > > > > I am going to push this now. Please let us know if it is working correctly > > afterwards for you. > > > > regards > > Stefan Schmidt > > Thanks. Honestly I don't have code that is affected right now. > I just was curious if the warnings of the ABI checker were all harmless and > did a test > with the code above. > > Regards, > Jean Rene Ok, with f619a2fbad2dcc81085f14cedaea4fc0df8f2837 Efl_Canvas_Text is fixed. I'm still not sure if a program is supposed to use these types directly in the first place. Similar issues occur with these types: Efl_Canvas_Vg_Container Efl_Canvas_Vg_Node Efl_Text_Cursor_Cursor Regards, Jean Rene ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
