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 c
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? :)
t
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 (ma
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
> > > eve
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"
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
elitair
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 w
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 w
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
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 mor
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 d
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_Suppor
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
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.
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]> wrot
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 chec
16 matches
Mail list logo
