Hello!
Dans son message intitulé « Re: [E-devel] E SVN: illogict IN
trunk/E-MODULES-EXTRA: alarm bling calendar cpu deskshow execwatch
flame forecasts language mail mem mpdule net news penguins photo rain
slideshow snow taskbar tclock uptime weather winselector wlan » du Thu,
16 Oct 2008
Hello all.
I'm writing to try to get all original sources and images for the edje
files on SVN. This would enable them to be regenerated on compilation
to avoid problem with recompilation (and thus quality loss for lossyly
compressed images) if any eet file format change happens in the future.
Hi all (especially Vincent),
I tried to compile Evil from the latest SVN revision (r36716), after
following the exact instructions from the wiki to get a working MinGW
development environment.
Here is the output:
$ ./autogen.sh
configure.ac:53: warning: _AC_Header_err_ is m4_require'd but not
Hey,
I tried to compile Evil from the latest SVN revision (r36716), after
following the exact instructions from the wiki to get a working MinGW
development environment.
Here is the output:
$ ./autogen.sh
configure.ac:53: warning: _AC_Header_err_ is m4_require'd but not m4_defun'd
Hi Vincent,
Thanks for the hint. Indeed the manual sequence for autofoo works better.
I had some compilation errors then, that I could fix using the
modifications in the attachment. They are just temporary workaround
that worked for me ; I suppose the presence of libsecur32.lib should
be checked
2008/10/16 Vincent Torri [EMAIL PROTECTED]:
On Thu, 16 Oct 2008, Lionel ORRY wrote:
Hi Vincent,
Thanks for the hint. Indeed the manual sequence for autofoo works better.
ok. I don't understand why, but when I have problems with autogen, I do
that. I asked on the autoconf ML about a
On Wed, 15 Oct 2008 13:29:10 +0200, Vincent Torri [EMAIL PROTECTED]
wrote:
On Wed, 15 Oct 2008, carlo\.bramix wrote:
Hello,
I have already implemented some of the functions you need in a lib
called
'Evil' (mmap, dlfcn, pwd.h, mkstemp,...). I use it for the EFL Windows
(XP
or Ce)
On Thu, 16 Oct 2008, Lionel ORRY wrote:
I had some compilation errors then, that I could fix using the
modifications in the attachment. They are just temporary workaround
that worked for me ; I suppose the presence of libsecur32.lib should
be checked (and conditional compilation of
Thank you Vincent,
that works perfectly. Remains only the problem for autoreconf. BTW, I
noticed Evil seems to be the only library in the EFL using
autoreconf.. The others have autogen.sh call the autofoo tools
subsequently. Maybe that would apply to Evil as well...
Now that the EFL are
On Thu, 16 Oct 2008, Lionel ORRY wrote:
that works perfectly. Remains only the problem for autoreconf. BTW, I
noticed Evil seems to be the only library in the EFL using
autoreconf.. The others have autogen.sh call the autofoo tools
subsequently. Maybe that would apply to Evil as well...
Hi,
I tried to create file lists by using Ecore_Path_Groups, but unfortunately I
didn't get a working result.
Is it possible that the path groups are broken, or do I just miss something?
I use it like this:
#include Ecore_Data.h
#include Ecore_Str.h
#include Ecore_File.h
int main() {
int i;
On monday, starting with revision 36622, all vital EFL components have
been configured to depend on copylefted code (eina is licensed under
LGPLv2.1). This is unfortunate, as it renders the existing BSD-style
license agreement essentially worthless. It is especially unfortunate as
the EFL seems to
On Fri, 17 Oct 2008 00:53:29 +0200 Michael Feiri [EMAIL PROTECTED] babbled:
this got debated to hell. the alternative was going to be watching developers
leave - ones wanting to add in better code but only wanting to do so if they
know their code will be free and improvements to it given back.
The attached patch fixes the ecore_path_group_available by removing the
senseless check on shared object suffix.
It also renames the function to ecore_path_group_available_get, to match the
ecore API.
Big thanks to pfritz for his help!
Greets,
thomasg
Index: ecore_path.c
Michael Feiri wrote:
On monday, starting with revision 36622, all vital EFL components have
been configured to depend on copylefted code (eina is licensed under
LGPLv2.1). This is unfortunate, as it renders the existing BSD-style
license agreement essentially worthless. It is especially
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The ebuilds seem out of date, i had a missing dep or to and all of eina
is missing from the enlightenment overlay.
Is someone working on this? I'm planning to create the missing parts
this weekend but don't want to double up.
Rich
- --
Rich Healey -
You can made a look at this small howto recopilatory that i have writed
just today
http://dev.elivecd.org/wiki/HowtoDevelopWithEFL
Thanatermesis
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
On Thu, Oct 16, 2008 at 7:53 PM, Michael Feiri [EMAIL PROTECTED] wrote:
On monday, starting with revision 36622, all vital EFL components have
been configured to depend on copylefted code (eina is licensed under
LGPLv2.1). This is unfortunate, as it renders the existing BSD-style
license
Rich Healey wrote:
The ebuilds seem out of date, i had a missing dep or to and all of eina
is missing from the enlightenment overlay.
Is someone working on this? I'm planning to create the missing parts
this weekend but don't want to double up.
Rich
You want to talk to vapier or gimpel -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Will Keaney wrote:
Rich Healey wrote:
The ebuilds seem out of date, i had a missing dep or to and all of eina
is missing from the enlightenment overlay.
Is someone working on this? I'm planning to create the missing parts
this weekend but don't
20 matches
Mail list logo
