From: Nicolas A. <agu...@gm...> - 2009-03-21 12:11:51
Attachments:
elm_add_disable_theme_build_option.patch
|
Hi, This patch add an option in configure to enable/disable theme build. It's usefull when you cross compile elementary and your host doesn't have edje_cc. (it's the case in GeexBox toolchain) Default behaviour build the theme. regards -- Nicolas Aguirre Mail: agu...@gm... Web: http://www.digital-corner.org |
From: Gustavo S. B. <bar...@pr...> - 2009-03-21 17:15:27
|
On Sat, Mar 21, 2009 at 9:11 AM, Nicolas Aguirre <agu...@gm...> wrote: > Hi, > This patch add an option in configure to enable/disable theme build. It's > usefull when you cross compile elementary and your host doesn't have > edje_cc. (it's the case in GeexBox toolchain) > Default behaviour build the theme. when you cross compile you're supposed to do: ./configure EDJE_CC=/path/to/native/edje_cc you can also make it "/bin/echo" and ignore the command altogether. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Carsten H. (T. R. <ra...@ra...> - 2009-03-22 04:07:32
|
On Sat, 21 Mar 2009 13:11:46 +0100 Nicolas Aguirre <agu...@gm...> said: > Hi, > This patch add an option in configure to enable/disable theme build. It's > usefull when you cross compile elementary and your host doesn't have > edje_cc. (it's the case in GeexBox toolchain) > Default behaviour build the theme. as gustavo said - export EDJE_CC=path/to/edje_cc or ./configure --with-edje-cc=/path/to/edje_cc as such... elementary wont work without its default theme - unless you have a complete replacement for it that is 100% complete - it's a good idea not to disable it or the build - changes in elm's code will also be accompanied by changes in default theme - so by doing what you do.. you are setting yourself up for pain and bugs (when as such there aren't any as you simply removed parts of changes done). :) i don't think what you are doing is a good idea, so i am not sure the patch is a good idea either. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Lars M. <la...@se...> - 2009-04-16 13:49:23
|
On Sun, Mar 22, 2009 at 03:07:20PM +1100, Carsten Haitzler wrote: > On Sat, 21 Mar 2009 13:11:46 +0100 Nicolas Aguirre <agu...@gm...> > said: > > > Hi, > > This patch add an option in configure to enable/disable theme build. It's > > usefull when you cross compile elementary and your host doesn't have > > edje_cc. (it's the case in GeexBox toolchain) > > Default behaviour build the theme. > > as gustavo said - > export EDJE_CC=path/to/edje_cc > or > ./configure --with-edje-cc=/path/to/edje_cc > > as such... elementary wont work without its default theme - unless you have a > complete replacement for it that is 100% complete - it's a good idea not to > disable it or the build - changes in elm's code will also be accompanied by > changes in default theme - so by doing what you do.. you are setting yourself > up for pain and bugs (when as such there aren't any as you simply removed parts > of changes done). :) i don't think what you are doing is a good idea, so i am > not sure the patch is a good idea either. :) I tried to cross build today using --with-edje-cc=/opt/e17/bin/edje_cc option, but I got some very strange errors from edje_cc: /opt/e17/bin/edje_cc: Wrote 858 bytes ( 1Kb) for "collections/51" collection entry /opt/e17/bin/edje_cc: Wrote 860 bytes ( 1Kb) for "collections/52" collection entry /opt/e17/bin/edje_cc: Wrote 862 bytes ( 1Kb) for "collections/53" collection entry /opt/e17/bin/edje_cc: Wrote 1195 bytes ( 1Kb) for "collections/54" collection entry /opt/e17/bin/edje_cc: Wrote 1136 bytes ( 1Kb) for "collections/55" collection entry /opt/e17/bin/edje_cc: Wrote 1201 bytes ( 1Kb) for "collections/56" collection entry /opt/e17/bin/edje_cc: Wrote 1133 bytes ( 1Kb) for "collections/57" collection entry /opt/e17/bin/edje_cc: Wrote 2085 bytes ( 2Kb) for "collections/58" collection entry /opt/e17/bin/edje_cc: Wrote 2101 bytes ( 2Kb) for "collections/59" collection entry /opt/e17/bin/edje_cc: Wrote 1372 bytes ( 1Kb) for "collections/60" collection entry /opt/e17/bin/edje_cc: Wrote 1321 bytes ( 1Kb) for "collections/61" collection entry /opt/e17/bin/edje_cc: Wrote 1512 bytes ( 1Kb) for "collections/62" collection entry /opt/e17/bin/edje_cc: Wrote 1460 bytes ( 1Kb) for "collections/63" collection entry /opt/e17/bin/edje_cc: Wrote 1076 bytes ( 1Kb) for "collections/64" collection entry /opt/e17/bin/edje_cc: Wrote 1058 bytes ( 1Kb) for "collections/65" collection entry /opt/e17/bin/edje_cc: Wrote 1087 bytes ( 1Kb) for "collections/66" collection entry /opt/e17/share/edje/include/edje.inc(190) : error 070: rational number support was not enabled /tmp/edje_cc.sma-tmp-og6F98(336) : error 070: rational number support was not enabled /tmp/edje_cc.sma-tmp-og6F98(337) : error 070: rational number support was not enabled /tmp/edje_cc.sma-tmp-og6F98(406) : error 070: rational number support was not enabled 4 Errors. /opt/e17/bin/edje_cc: Error. Compiling script code not clean. make[2]: *** [default.edj] Error 255 I tried setting the PATH and EMBRYO_PREFIX, but nothing worked. Any idea why this happens? Thanks Lars Munch |
From: Nicolas A. <agu...@gm...> - 2009-03-23 08:06:46
|
On Sun, Mar 22, 2009 at 5:07 AM, Carsten Haitzler <ra...@ra...>wrote: > > as such... elementary wont work without its default theme - unless you have > a > complete replacement for it that is 100% complete - it's a good idea not to > disable it or the build - changes in elm's code will also be accompanied by > changes in default theme - so by doing what you do.. you are setting > yourself > up for pain and bugs (when as such there aren't any as you simply removed > parts > of changes done). :) i don't think what you are doing is a good idea, so i > am > not sure the patch is a good idea either. :) > <ra...@ra...> > Yep you're right, Today I just override elementary theme with my own implementation of genlist for example (with minimal changes). I don't want to dissociate elm and theme, and don't want to remove the default one, but just want to provide the edje file for those that doesn't have efl on their host computer. But as you and gustavo said it's not the best solution. We will compile EFL and edje_cc in host toolchain. Thank you both for your comments :) -- Nicolas Aguirre Mail: agu...@gm... Web: http://www.digital-corner.org |
From: Carsten H. (T. R. <ra...@ra...> - 2009-03-23 08:16:23
|
On Mon, 23 Mar 2009 09:06:34 +0100 Nicolas Aguirre <agu...@gm...> said: > On Sun, Mar 22, 2009 at 5:07 AM, Carsten Haitzler <ra...@ra...>wrote: > > > > > as such... elementary wont work without its default theme - unless you have > > a > > complete replacement for it that is 100% complete - it's a good idea not to > > disable it or the build - changes in elm's code will also be accompanied by > > changes in default theme - so by doing what you do.. you are setting > > yourself > > up for pain and bugs (when as such there aren't any as you simply removed > > parts > > of changes done). :) i don't think what you are doing is a good idea, so i > > am > > not sure the patch is a good idea either. :) > > <ra...@ra...> > > > > Yep you're right, Today I just override elementary theme with my own > implementation of genlist for example (with minimal changes). I don't want > to dissociate elm and theme, and don't want to remove the default one, but > just want to provide the edje file for those that doesn't have efl on their > host computer. But as you and gustavo said it's not the best solution. We > will compile EFL and edje_cc in host toolchain. Thank you both for your > comments :) you should pay attention to openembedded. many bits of software require running of tools during build that are not always "gcc" and "make". openembedded has the concept of "native" packages. build a "native" version of the dependency you need (eg edje in this case) and install it in a "staging" area to be used during build. it doesnt need installing on the host fs - just in a fs tree within the build system that is in $PATH and whose libs are in LD_LIBRARY_PATH that the build system sets up. this is the "right" solution. it simply generates the dependencies needed to run at build time and has them accessible. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Nicolas A. <agu...@gm...> - 2009-03-23 08:32:22
|
On Mon, Mar 23, 2009 at 9:16 AM, Carsten Haitzler <ra...@ra...>wrote: > > you should pay attention to openembedded. many bits of software require > running > of tools during build that are not always "gcc" and "make". openembedded > has > the concept of "native" packages. build a "native" version of the > dependency > you need (eg edje in this case) and install it in a "staging" area to be > used > during build. it doesnt need installing on the host fs - just in a fs tree > within the build system that is in $PATH and whose libs are in > LD_LIBRARY_PATH > that the build system sets up. this is the "right" solution. it simply > generates the dependencies needed to run at build time and has them > accessible. > > afaik Geexbox toolchain does exactly the same. gcc and other tools are already compiled natively and we have to expand some rules to build EFL in this native environnement. -- Nicolas Aguirre Mail: agu...@gm... Web: http://www.digital-corner.org |
From: Carsten H. (T. R. <ra...@ra...> - 2009-03-23 09:29:42
|
On Mon, 23 Mar 2009 09:32:15 +0100 Nicolas Aguirre <agu...@gm...> said: > On Mon, Mar 23, 2009 at 9:16 AM, Carsten Haitzler <ra...@ra...>wrote: > > > > > you should pay attention to openembedded. many bits of software require > > running > > of tools during build that are not always "gcc" and "make". openembedded > > has > > the concept of "native" packages. build a "native" version of the > > dependency > > you need (eg edje in this case) and install it in a "staging" area to be > > used > > during build. it doesnt need installing on the host fs - just in a fs tree > > within the build system that is in $PATH and whose libs are in > > LD_LIBRARY_PATH > > that the build system sets up. this is the "right" solution. it simply > > generates the dependencies needed to run at build time and has them > > accessible. > > > > > afaik Geexbox toolchain does exactly the same. gcc and other tools are > already compiled natively and we have to expand some rules to build EFL in > this native environnement. yup. that's what you need to do :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |