From: Tilman S. <ti...@co...> - 2005-04-19 18:35:46
|
Hi, IMHO it sucks that if you want to link your application to Ecore, you have to link in all of its subsystems. This isn't much of an issue for the generic app that uses ecore_evas, but it sucks if all you need is the E-ecore and the config subsystem e.g. I suggest to handle this the same way we do it in Esmart: "ecore-config --libs" only includes "-lecore", if you need the subsystems, you'll have to add the other linker switches yourself. Comments? -- Regards, Tilman |
From: M. <and...@gm...> - 2005-04-19 18:51:56
|
On Tue, 2005-04-19 at 20:35 +0200, Tilman Sauerbeck wrote: > Hi, > IMHO it sucks that if you want to link your application to Ecore, you > have to link in all of its subsystems. This isn't much of an issue for > the generic app that uses ecore_evas, but it sucks if all you need is > the E-ecore and the config subsystem e.g. > > I suggest to handle this the same way we do it in Esmart: > "ecore-config --libs" only includes "-lecore", if you need the > subsystems, you'll have to add the other linker switches yourself. > > Comments? > >From what I have seen about the EFL, you should only get what you need. Based on the discussion between dj2 and Handy (about the IPC border_list issue), you should only get what you ask for, so you don't clog up things. My $0.02 |
From: David S. <dav...@gm...> - 2005-04-19 22:31:59
|
On 4/20/05, Tilman Sauerbeck <ti...@co...> wrote: > Hi, > IMHO it sucks that if you want to link your application to Ecore, you > have to link in all of its subsystems. This isn't much of an issue for > the generic app that uses ecore_evas, but it sucks if all you need is > the E-ecore and the config subsystem e.g. >=20 > I suggest to handle this the same way we do it in Esmart: > "ecore-config --libs" only includes "-lecore", if you need the > subsystems, you'll have to add the other linker switches yourself. >=20 > Comments? I am a newbie to EFL and just getting back into C and gcc after 4 years off= ... It sounds like the issue you are describing is the issue I was having a few days back when I was trying to pull in Ecore and Evas_Ecore (I think), but then got a huge list of errors at link time, and went to bed early. So as an EFL newbie, I would welcome such a change (^_^) David >=20 > -- > Regards, > Tilman >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: New Crystal Reports XI. > Version 11 adds new functionality designed to reduce time involved in > creating, integrating, and deploying reporting solutions. Free runtime in= fo, > new features, or free trial, at: http://www.businessobjects.com/devxi/728 > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Carsten H. (T. R. <ra...@ra...> - 2005-04-20 02:55:41
|
On Tue, 19 Apr 2005 20:35:41 +0200 Tilman Sauerbeck <ti...@co...> babbled: > Hi, > IMHO it sucks that if you want to link your application to Ecore, you > have to link in all of its subsystems. This isn't much of an issue for > the generic app that uses ecore_evas, but it sucks if all you need is > the E-ecore and the config subsystem e.g. that's true. :) > I suggest to handle this the same way we do it in Esmart: > "ecore-config --libs" only includes "-lecore", if you need the > subsystems, you'll have to add the other linker switches yourself. hmm - i see not big problem with this - as long as everything updates to match... i guess we can just say "fuck it" to any system that doesn't handle shared lib linking :) (ecore_x, ecore_evas etc.) > Comments? > > -- > Regards, > Tilman > > > ------------------------------------------------------- > This SF.Net email is sponsored by: New Crystal Reports XI. > Version 11 adds new functionality designed to reduce time involved in > creating, integrating, and deploying reporting solutions. Free runtime info, > new features, or free trial, at: http://www.businessobjects.com/devxi/728 > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 ra...@de... Tokyo, Japan (東京 日本) |
From: Tilman S. <ti...@co...> - 2005-04-20 15:17:22
|
Carsten Haitzler <ra...@ra...> [2005-04-20 11:56]: > > I suggest to handle this the same way we do it in Esmart: > > "ecore-config --libs" only includes "-lecore", if you need the > > subsystems, you'll have to add the other linker switches yourself. > > hmm - i see not big problem with this - as long as everything updates to match... i guess we can just say "fuck it" to any system that doesn't handle shared lib linking :) (ecore_x, ecore_evas etc.) Not sure I understood you correctly - do you agree with my suggestion? -- Regards, Tilman |
From: Carsten H. (T. R. <ra...@ra...> - 2005-04-22 02:56:29
|
On Wed, 20 Apr 2005 17:16:39 +0200 Tilman Sauerbeck <ti...@co...> babbled: > Carsten Haitzler <ra...@ra...> [2005-04-20 11:56]: > > > I suggest to handle this the same way we do it in Esmart: > > > "ecore-config --libs" only includes "-lecore", if you need the > > > subsystems, you'll have to add the other linker switches yourself. > > > > hmm - i see not big problem with this - as long as everything updates to match... i guess we can just say "fuck it" to any system that doesn't handle shared lib linking :) (ecore_x, ecore_evas etc.) > > Not sure I understood you correctly - do you agree with my suggestion? partly - in principle yes, but in practise its a bit trickier as the separate ecore libs have other dependencies that may be handled by shared lib deps - but maybe not. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 ra...@de... Tokyo, Japan (東京 日本) |
From: Michael J. <e-...@ka...> - 2005-04-20 17:46:28
|
On Wednesday, 20 April 2005, at 17:16:39 (+0200), Tilman Sauerbeck wrote: > > hmm - i see not big problem with this - as long as everything > > updates to match... i guess we can just say "fuck it" to any > > system that doesn't handle shared lib linking :) (ecore_x, > > ecore_evas etc.) > > Not sure I understood you correctly - do you agree with my suggestion? I think it's important to not say "fuck it" to such systems; many many many of them still exist. The better answer is to have --libs-evas and --libs-ipc and so forth for each subsystem. This allows just linking with ecore (--libs) while still providing linker flags for the modules as well. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "I guess the time is right for us to say we'll take our time and live our lives together day by day. We'll make a wish and send it on a prayer. We know our dreams will all come true with love that we can share." -- Firehouse, "Love of a Lifetime" |
From: Carsten H. (T. R. <ra...@ra...> - 2005-04-22 02:56:29
|
On Wed, 20 Apr 2005 13:46:22 -0400 Michael Jennings <e-...@ka...> babbled: > On Wednesday, 20 April 2005, at 17:16:39 (+0200), > Tilman Sauerbeck wrote: > > > > hmm - i see not big problem with this - as long as everything > > > updates to match... i guess we can just say "fuck it" to any > > > system that doesn't handle shared lib linking :) (ecore_x, > > > ecore_evas etc.) > > > > Not sure I understood you correctly - do you agree with my suggestion? > > I think it's important to not say "fuck it" to such systems; many many > many of them still exist. though on the other side of that argument is... most of those "Existing" systems are now old machines which are quite slow and likely e17 is not optimal for it (though it scales down well). :) > The better answer is to have --libs-evas and --libs-ipc and so forth > for each subsystem. This allows just linking with ecore (--libs) > while still providing linker flags for the modules as well. well that's the other option :) > Michael > > -- > Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> > n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) > ----------------------------------------------------------------------- > "I guess the time is right for us to say we'll take our time and live > our lives together day by day. We'll make a wish and send it on a > prayer. We know our dreams will all come true with love that we can > share." -- Firehouse, "Love of a Lifetime" > > > ------------------------------------------------------- > This SF.Net email is sponsored by: New Crystal Reports XI. > Version 11 adds new functionality designed to reduce time involved in > creating, integrating, and deploying reporting solutions. Free runtime info, > new features, or free trial, at: http://www.businessobjects.com/devxi/728 > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 ra...@de... Tokyo, Japan (東京 日本) |