[E-devel] Ecore_Support
Hi all, After I developed Ecore_IM I figured it out that a lot of code, macros, etc. are duplicated all around the code (EAPI definition, ECORE_MAGIC check, ...). I would like to propose a support library (Ecore_Support) that all ecore modules could use, maybe even other modules as e_dbus (to check for NULL pointer and return if fail, see http://marc.info/?l=enlightenment-devel&m=119536252710044&w=2). Ecore_Support.h could define EAPI, some helper functions as ECORE_MAGIC_CHECK_RETURN, ECORE_MAGIC_CHECK_RETURN_VAL, etc. That would remove a lot of duplicated code. What do you think about it? Any ideas of helper functions that could be in Ecore_Support? If you are interested I can do it and provide a patch. BR -- Andre Moreira Magalhaes (andrunko) Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] Skype: andrunko Blog:http://andrunko.blogspot.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
Re: [E-devel] Ecore_Support
Rather than introducing another internal dependency that may complicate things when ecore is eventually split up, could these go in the Ecore_Data definitions? I believe everything in ecore depends on this either directly or indirectly anyways. On 11/18/07, Andre Magalhaes <[EMAIL PROTECTED]> wrote: > Hi all, > > After I developed Ecore_IM I figured it out that a lot of code, macros, etc. > are duplicated all around the code (EAPI definition, ECORE_MAGIC > check, ...). > I would like to propose a support library (Ecore_Support) that all ecore > modules could use, maybe even other modules as e_dbus (to check > for NULL pointer and return if fail, > see http://marc.info/?l=enlightenment-devel&m=119536252710044&w=2). > > Ecore_Support.h could define EAPI, some helper functions as > ECORE_MAGIC_CHECK_RETURN, ECORE_MAGIC_CHECK_RETURN_VAL, > etc. That would remove a lot of duplicated code. > > What do you think about it? Any ideas of helper functions that could be in > Ecore_Support? > If you are interested I can do it and provide a patch. > > BR > > -- > Andre Moreira Magalhaes (andrunko) > > Jabber: [EMAIL PROTECTED] > MSN: [EMAIL PROTECTED] > Skype: andrunko > Blog:http://andrunko.blogspot.com > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > 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 > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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] E_CONFIG and --with-enlightenment-config
does anyone actually need --with-enlightenment-config ? its functionality can already be achieved by doing E_CONFIG=... otherwise i'll just toss it -mike signature.asc Description: This is a digitally signed message part. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
Re: [E-devel] Ecore_Support
On Nov 18, 2007 2:07 PM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: > Rather than introducing another internal dependency that may > complicate things when ecore is eventually split up, could these go in > the Ecore_Data definitions? I believe everything in ecore depends on > this either directly or indirectly anyways. Yeah, the idea of adding Ecore_Support is not to really have an Ecore_Support.h or anything, but to have a place where these (EAPI, ...) definitions could be added and stop duplicated code all over the place. Ecore_Data may be a good place to add these. BR -- Andre Moreira Magalhaes (andrunko) Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] Skype: andrunko Blog:http://andrunko.blogspot.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
Re: [E-devel] Ecore_Support
On Nov 18, 2007 11:52 AM, Andre Magalhaes <[EMAIL PROTECTED]> wrote: > Hi all, > > After I developed Ecore_IM I figured it out that a lot of code, macros, etc. > are duplicated all around the code (EAPI definition, ECORE_MAGIC > check, ...). > I would like to propose a support library (Ecore_Support) that all ecore > modules could use, maybe even other modules as e_dbus (to check > for NULL pointer and return if fail, > see http://marc.info/?l=enlightenment-devel&m=119536252710044&w=2). > Just a side note, I really think we should stop stuffing Ecore with all of this stuff. I would vote for splitting it up asap and not adding any more stuff in there. -- Hisham Mardam Bey http://hisham.cc/ +1-514-713-9312 Codito Ergo Sum (I Code Therefore I Am) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
Re: [E-devel] Ecore_Support
On Nov 18, 2007 4:55 PM, Hisham Mardam Bey <[EMAIL PROTECTED]> wrote: > Just a side note, I really think we should stop stuffing Ecore with > all of this stuff. I would vote for splitting it up asap and not > adding any more stuff in there. While I agree, what are the plans of a split? Will it be done soon? While we don't do it, we could add these definitions in Ecore_Data.h, or even Ecore_Support.h and include it on Ecore.h so everybody that uses Ecore.h could use them and remove the duplicated code all over the place. BR -- Andre Moreira Magalhaes (andrunko) Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] Skype: andrunko Blog:http://andrunko.blogspot.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
Re: [E-devel] Ecore_Support
On Nov 18, 2007 3:14 PM, Andre Magalhaes <[EMAIL PROTECTED]> wrote: > On Nov 18, 2007 4:55 PM, Hisham Mardam Bey <[EMAIL PROTECTED]> wrote: > > Just a side note, I really think we should stop stuffing Ecore with > > all of this stuff. I would vote for splitting it up asap and not > > adding any more stuff in there. > While I agree, what are the plans of a split? Will it be done soon? While we > don't do it, we could add these definitions in Ecore_Data.h, or even > Ecore_Support.h and > include it on Ecore.h so everybody that uses Ecore.h could use them > and remove the > duplicated code all over the place. > The situation is, everyone knows we should split up ecore, but everyone just keeps adding to it because no one is willing to split it up and cope with fixing the breakage. The more this keeps on being done, the harder its going to be to fix it all once its broken. We better do it now than wait for more code to creep in there. Someone has to do it, and if you guys dont mind, well, I'm personally all for it. -- Hisham Mardam Bey http://hisham.cc/ +1-514-713-9312 Codito Ergo Sum (I Code Therefore I Am) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
Re: [E-devel] Ecore_Support
On Nov 18, 2007 5:16 PM, Hisham Mardam Bey <[EMAIL PROTECTED]> wrote: > The situation is, everyone knows we should split up ecore, but > everyone just keeps adding to it because no one is willing to split it > up and cope with fixing the breakage. The more this keeps on being > done, the harder its going to be to fix it all once its broken. > > We better do it now than wait for more code to creep in there. Someone > has to do it, and if you guys dont mind, well, I'm personally all for > it. But what is the idea of a split. Put every module in a different package? Rename them? Why is it needed, as every module already are independent in a certain way of each other. Own pkgconfig file, own library, So basically what is needed for a split? We could do it, but first we need to know what needs to be done. BR -- Andre Moreira Magalhaes (andrunko) Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] Skype: andrunko Blog:http://andrunko.blogspot.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
Re: [E-devel] Ecore_Support
On Nov 18, 2007 3:19 PM, Andre Magalhaes <[EMAIL PROTECTED]> wrote: > On Nov 18, 2007 5:16 PM, Hisham Mardam Bey <[EMAIL PROTECTED]> wrote: > > The situation is, everyone knows we should split up ecore, but > > everyone just keeps adding to it because no one is willing to split it > > up and cope with fixing the breakage. The more this keeps on being > > done, the harder its going to be to fix it all once its broken. > > > > We better do it now than wait for more code to creep in there. Someone > > has to do it, and if you guys dont mind, well, I'm personally all for > > it. > But what is the idea of a split. Put every module in a different > package? Rename them? > Why is it needed, as every module already are independent in a certain > way of each other. > Own pkgconfig file, own library, > So basically what is needed for a split? > We could do it, but first we need to know what needs to be done. > The main idea back then was to have separate libraries instead of constantly growing Ecore itself. I think its cleaner that way, easier for people to find things, and allows people to manage and contribute more easily. Jorge had some thoughts about this in the past, maybe he can comment as well? -- Hisham Mardam Bey http://hisham.cc/ +1-514-713-9312 Codito Ergo Sum (I Code Therefore I Am) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
Re: [E-devel] Ecore_Support
On Nov 18, 2007 5:19 PM, Andre Magalhaes <[EMAIL PROTECTED]> wrote: > On Nov 18, 2007 5:16 PM, Hisham Mardam Bey <[EMAIL PROTECTED]> wrote: > > The situation is, everyone knows we should split up ecore, but > > everyone just keeps adding to it because no one is willing to split it > > up and cope with fixing the breakage. The more this keeps on being > > done, the harder its going to be to fix it all once its broken. > > > > We better do it now than wait for more code to creep in there. Someone > > has to do it, and if you guys dont mind, well, I'm personally all for > > it. > But what is the idea of a split. Put every module in a different > package? Rename them? > Why is it needed, as every module already are independent in a certain > way of each other. > Own pkgconfig file, own library, > So basically what is needed for a split? > We could do it, but first we need to know what needs to be done. yes, just that... turran did this with proto/ecore_li (actually it's a new lib, so it was just not added, instead of split). -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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] Nightly build log for E17 on 2007-11-18 15:50:54 -0800
Build log for Enlightenment DR 0.17 on 2007-11-18 15:50:54 -0800 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: edvi http://download.enlightenment.org/tests/logs/edvi.log eflpp http://download.enlightenment.org/tests/logs/eflpp.log elitaire http://download.enlightenment.org/tests/logs/elitaire.log embrace http://download.enlightenment.org/tests/logs/embrace.log empower http://download.enlightenment.org/tests/logs/empower.log engage http://download.enlightenment.org/tests/logs/engage.log epdf http://download.enlightenment.org/tests/logs/epdf.log ephoto http://download.enlightenment.org/tests/logs/ephoto.log equate http://download.enlightenment.org/tests/logs/equate.log evolve http://download.enlightenment.org/tests/logs/evolve.log ewl http://download.enlightenment.org/tests/logs/ewl.log examine http://download.enlightenment.org/tests/logs/examine.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, cpu, deskshow, eclair, ecore, edb, e_dbus, edje_editor, edje, edje_viewer, eet, eflame, efreet, elapse, elation, elicit, e, embryo, emotion, emphasis, emu, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, e_phys, epsilon, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, exhibit, exml, expedite, express, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, net, news, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
Re: [E-devel] E_CONFIG and --with-enlightenment-config
On Sun, 18 Nov 2007 12:41:00 -0500 Mike Frysinger <[EMAIL PROTECTED]> babbled: > does anyone actually need --with-enlightenment-config ? its functionality > can already be achieved by doing E_CONFIG=... what is that an option to? :) -- - 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 2005. 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
Re: [E-devel] Ecore_Support
On Nov 18, 2007 9:51 PM, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > On Nov 18, 2007 5:19 PM, Andre Magalhaes <[EMAIL PROTECTED]> wrote: > > On Nov 18, 2007 5:16 PM, Hisham Mardam Bey <[EMAIL PROTECTED]> wrote: > > > The situation is, everyone knows we should split up ecore, but > > > everyone just keeps adding to it because no one is willing to split it > > > up and cope with fixing the breakage. The more this keeps on being > > > done, the harder its going to be to fix it all once its broken. > > > > > > We better do it now than wait for more code to creep in there. Someone > > > has to do it, and if you guys dont mind, well, I'm personally all for > > > it. > > But what is the idea of a split. Put every module in a different > > package? Rename them? > > Why is it needed, as every module already are independent in a certain > > way of each other. > > Own pkgconfig file, own library, > > So basically what is needed for a split? > > We could do it, but first we need to know what needs to be done. > > yes, just that... turran did this with proto/ecore_li (actually it's a > new lib, so it was just not added, instead of split). Indeed, that's my idea, just move every ecore subsytem to its own directory outside ecore (at least as a beginning). I did this with ecore_li under proto and also edata (which is ecore_data) i sent an email to the list but got almost no feedback about it. The problem splitting ecore_data is the large amount of projects to fix both code and autotools stuff but it's doable in case we agree. > -- > Gustavo Sverzut Barbieri > -- > Jabber: [EMAIL PROTECTED] >MSN: [EMAIL PROTECTED] > ICQ#: 17249123 > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > 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 > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
Re: [E-devel] Ecore_Support
On Mon, 19 Nov 2007 01:02:40 +0100 "Jorge Luis Zapata Muga" <[EMAIL PROTECTED]> babbled: my plan was just to split it with no renaming. ecore builds as ecore. ecore_evas builds as ecore_evas with its own configure etc. no need to change names of api calls etc. at all. this won't break any apps (maybe just the configure scripts as the pkgconfig stuff will split).. and thus this can be punted off until later. > On Nov 18, 2007 9:51 PM, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > > On Nov 18, 2007 5:19 PM, Andre Magalhaes <[EMAIL PROTECTED]> wrote: > > > On Nov 18, 2007 5:16 PM, Hisham Mardam Bey <[EMAIL PROTECTED]> > > > wrote: > > > > The situation is, everyone knows we should split up ecore, but > > > > everyone just keeps adding to it because no one is willing to split it > > > > up and cope with fixing the breakage. The more this keeps on being > > > > done, the harder its going to be to fix it all once its broken. > > > > > > > > We better do it now than wait for more code to creep in there. Someone > > > > has to do it, and if you guys dont mind, well, I'm personally all for > > > > it. > > > But what is the idea of a split. Put every module in a different > > > package? Rename them? > > > Why is it needed, as every module already are independent in a certain > > > way of each other. > > > Own pkgconfig file, own library, > > > So basically what is needed for a split? > > > We could do it, but first we need to know what needs to be done. > > > > yes, just that... turran did this with proto/ecore_li (actually it's a > > new lib, so it was just not added, instead of split). > > Indeed, that's my idea, just move every ecore subsytem to its own > directory outside ecore (at least as a beginning). I did this with > ecore_li under proto and also edata (which is ecore_data) i sent an > email to the list but got almost no feedback about it. The problem > splitting ecore_data is the large amount of projects to fix both code > and autotools stuff but it's doable in case we agree. > > > -- > > Gustavo Sverzut Barbieri > > -- > > Jabber: [EMAIL PROTECTED] > >MSN: [EMAIL PROTECTED] > > ICQ#: 17249123 > > Skype: gsbarbieri > > Mobile: +55 (81) 9927 0010 > > > > > > - > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > 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 > > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > 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 > -- - 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 2005. 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
Re: [E-devel] E_CONFIG and --with-enlightenment-config
On Sunday 18 November 2007, Carsten Haitzler wrote: > On Sun, 18 Nov 2007 12:41:00 -0500 Mike Frysinger <[EMAIL PROTECTED]> babbled: > > does anyone actually need --with-enlightenment-config ? its > > functionality can already be achieved by doing E_CONFIG=... > > what is that an option to? :) the path to `enlightenment-config` -mike signature.asc Description: This is a digitally signed message part. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
Re: [E-devel] Ecore_Support
On Nov 18, 2007 11:09 PM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Mon, 19 Nov 2007 01:02:40 +0100 "Jorge Luis Zapata Muga" > <[EMAIL PROTECTED]> babbled: > > my plan was just to split it with no renaming. ecore builds as ecore. > ecore_evas builds as ecore_evas with its own configure etc. no need to change > names of api calls etc. at all. this won't break any apps (maybe just the > configure scripts as the pkgconfig stuff will split).. and thus this can be > punted off until later. That would be easy to do, and afaik no app would have to change its configure script, as most of the ecore libs (if not all) already have their own pkgconfig files. What about the Ecore_Support that this thread was about, hehe. Are you interested in it? Should we change Ecore_Data.h or should we add a new Ecore_Support.h (EAPI definitions, ECORE_MAGIC_CHECK, ...) and include it on Ecore.h so it wouldn't break anything? I really dislike to have to copy, paste code all over the place. Raster? BR -- Andre Moreira Magalhaes (andrunko) Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] Skype: andrunko Blog:http://andrunko.blogspot.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
