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
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 09:47:45 +1000, David Seikel [EMAIL PROTECTED] nous a donné l'occasion de lire : On Wed, 15 Oct 2008 13:04:36 -0700 Enlightenment SVN [EMAIL PROTECTED] wrote: Log: And finally recompile e extra modules' edje files. All edje files on repository should be using the latest eet version. Actually, all files that get compiled should be compiled be the make files or whatever if we have source in SVN. For most (all?) edje files we should have the source in SVN. Well, it would be great if it were the case, but it's not. I'll try to get all of them. Chidambar signature.asc Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Edje files on SVN
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. Thank you in advance. Chidambar signature.asc Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Evil, svn trunk] autogen.sh failed on WinXP
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 m4_defun'd autoconf/headers.m4:218: AC_CHECK_HEADERS_ONCE is expanded from... configure.ac:53: the top level configure.ac:53: warning: _AC_Header_err_ is m4_require'd but not m4_defun'd autoconf/headers.m4:218: AC_CHECK_HEADERS_ONCE is expanded from... configure.ac:53: the top level configure.ac:53: warning: _AC_Header_err_ is m4_require'd but not m4_defun'd autoconf/headers.m4:218: AC_CHECK_HEADERS_ONCE is expanded from... configure.ac:53: the top level configure.ac:53: warning: _AC_Header_err_ is m4_require'd but not m4_defun'd autoconf/headers.m4:218: AC_CHECK_HEADERS_ONCE is expanded from... configure.ac:53: the top level configure:13457: error: possibly undefined macro: _AC_Header_err_ If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/local/bin/autoconf failed with exit status: 1 configure: error: cannot find install-sh or install.sh in . ./.. ./../.. Autoconf version is 2.61 (like said in the wiki). Does anybody see where that comes from ? The recent configure.in-configure.ac renaming maybe ? Thanks for your help and all the great work. regards, Lionel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evil, svn trunk] autogen.sh failed on WinXP
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 autoconf/headers.m4:218: AC_CHECK_HEADERS_ONCE is expanded from... configure.ac:53: the top level configure.ac:53: warning: _AC_Header_err_ is m4_require'd but not m4_defun'd autoconf/headers.m4:218: AC_CHECK_HEADERS_ONCE is expanded from... configure.ac:53: the top level configure.ac:53: warning: _AC_Header_err_ is m4_require'd but not m4_defun'd autoconf/headers.m4:218: AC_CHECK_HEADERS_ONCE is expanded from... configure.ac:53: the top level configure.ac:53: warning: _AC_Header_err_ is m4_require'd but not m4_defun'd autoconf/headers.m4:218: AC_CHECK_HEADERS_ONCE is expanded from... configure.ac:53: the top level configure:13457: error: possibly undefined macro: _AC_Header_err_ If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/local/bin/autoconf failed with exit status: 1 configure: error: cannot find install-sh or install.sh in . ./.. ./../.. Autoconf version is 2.61 (like said in the wiki). Does anybody see where that comes from ? The recent configure.in-configure.ac renaming maybe ? Strange. AC_CHECK_HEADERS_ONCE has been introduced in autoconf 2.59c, so your version is good enough. Try to execute yourself (without using autogen.sh) all the autotools commands: aclocal -I m4 autoheader autoconf libtoolize --copy --automake automake --add-missing --copy --gnu I don't have that problem, but it's on linux with cross-compilation for Windows CE. I'll try this evening on Windows with MinGW Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evil, svn trunk] autogen.sh failed on WinXP
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 (and conditional compilation of evil_pwd.c adjusted as a
consequence), and the replacement of _WIN32_WCE=0x0420 by
_WIN32_WINNT=0x0501 is, of course, only for my machine.
Does autoconf have a macro to get WINVER ? I used the following
snippet of code to get my version :
getver.c
#include stdio.h
#include windows.h
int main()
{
printf(0x%04X\n,_winver);
return 0;
}
---
but I suppose there's a more efficient way that could be embedded in
configure.ac.
Anyway, the attached could help _me_ compile Evil. I can go on with the EFL...
regards,
Lionel
2008/10/16 Vincent Torri [EMAIL PROTECTED]:
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
autoconf/headers.m4:218: AC_CHECK_HEADERS_ONCE is expanded from...
configure.ac:53: the top level
configure.ac:53: warning: _AC_Header_err_ is m4_require'd but not
m4_defun'd
autoconf/headers.m4:218: AC_CHECK_HEADERS_ONCE is expanded from...
configure.ac:53: the top level
configure.ac:53: warning: _AC_Header_err_ is m4_require'd but not
m4_defun'd
autoconf/headers.m4:218: AC_CHECK_HEADERS_ONCE is expanded from...
configure.ac:53: the top level
configure.ac:53: warning: _AC_Header_err_ is m4_require'd but not
m4_defun'd
autoconf/headers.m4:218: AC_CHECK_HEADERS_ONCE is expanded from...
configure.ac:53: the top level
configure:13457: error: possibly undefined macro: _AC_Header_err_
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/local/bin/autoconf failed with exit status: 1
configure: error: cannot find install-sh or install.sh in . ./..
./../..
Autoconf version is 2.61 (like said in the wiki).
Does anybody see where that comes from ? The recent
configure.in-configure.ac renaming maybe ?
Strange. AC_CHECK_HEADERS_ONCE has been introduced in autoconf 2.59c, so
your version is good enough.
Try to execute yourself (without using autogen.sh) all the autotools
commands:
aclocal -I m4
autoheader
autoconf
libtoolize --copy --automake
automake --add-missing --copy --gnu
I don't have that problem, but it's on linux with cross-compilation for
Windows CE. I'll try this evening on Windows with MinGW
Vincent
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evil, svn trunk] autogen.sh failed on WinXP
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 similar problem some times ago, no answer yet. 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 evil_pwd.c adjusted as a consequence) actually, no need to be checked: you run mingw, so you are sure that that static lib exists. I'll fix that when I switch to Win XP this week end. First, I have to check something on Win CE. and the replacement of _WIN32_WCE=0x0420 by _WIN32_WINNT=0x0501 is, of course, only for my machine. I'm wondering if setting _WIN32_WINNT is really necessary, but I plan to actually target at least Win XP, so setting it to 0x0501 is not a bad idea. I'll have to check anyway. On the contrary, setting _WIN32_WCE directly in Makefile.am is not good at all :) actually, it is necessary, or else an enum value is not defined for lower WINVER or _WIN32_WINNT versions (these values are basically the same. I don't know when they differ). So maybe hard-code it somewhere could help... Does autoconf have a macro to get WINVER ? I used the following snippet of code to get my version : [snip] I don't think that autoconf provides such macro. Evil is in a good shape. I'm considering doing a release soon, and binaries for Win XP and Win CE. Thank you Vincent I'd rather thank YOU for all the hard work trying to port those fantastic libraries to windows. Thumbs up. Lionel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] IMLIB2 ported to mingw+msys
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) port. Maybe you could look at my code, improve it if you think it's needed, and make imlib2 Windows port depending on Evil If all that's needed is included in the patch I think it's a bit much to have to depend on another (unreleased) library. Otherwise, i would say that you need to add AC_LIBTOOL_WIN32_DLL in configure.ac too so that libtool is aware that you have a Windows port. Sorry, my fault, I forgot to tell you that I also upgraded to a newer version these files: config.guess config.sub depcomp install-sh ltmain.sh missing These should all be generated when running ./autogen.sh. AC_LIBTOOL_WIN32_DLL seems deprecated and I think this could be the reason because it works fine here on my PC. It's not a problem to add it anyways. it's deprecated but the new way to do it requires a recent version of libtool (= 1.9b, more precisely). You can say that that version was released in 2004 and we are in 2008. I have absolutely no problem in using the new way to do that, but as it is Kim who uses really imlib2 in e16, I would wait for his opinion about using or not a recent version of libtool. I don't think imlib2 should depend on a libtool version 1.5.x. I also forgot to add $LT_LDFLAGS into src/modules/filters/Makefile.am (my mistake): it is not possible to create shared libs without that flag, I discovered it only when I checked the content of /lib directory after I did the make install, if I must provide a new patch with this little fix, just let me know. Yes, please. that should be the new way of doing things with libtool. Please also excuse my ignorance, but I have not found a package called EFL into download page at sourceforge... EFL means Enlightenment fundation libraries. It is a set of libraries that e17 uses (eet, evas, ...). actually I was just trying to build IMLIB2 because libcaca checked if it was available. I tried to do it in the simplest manner (especially because I'm a developer for Windows and not very expert with unix stuff) You interest me ! I am searching some help for the Windows port of the EFL, especially because I'm not a Windows developper. If you want to join the task force (and if you have time, of course), I would be glad to have someone more on that port :) Anyway, I think that this port should be done in the same way than the other EFL. Using Evil means that the Windows code it located at one place only. Less things to fix. And I would be happy if you have time to review the code in Evil :) regards Vincent Basically I'm fine with these changes. However: - We should make a 1.4.2 release of current svn before doing this. - tga support wasn't built when I tested (no configure arguments), I think the HAVE_MMAP test is wrong. - In configure.in (which has been renamed to configure.ac) you set HAVE_SIGSETJMP but in loader_jpeg.c you use HAVE_SIGJMP_BUF. - Some dos style CRLF line endings have crept in (e.g. loader_gif.c). /Kim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evil, svn trunk] autogen.sh failed on WinXP
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 evil_pwd.c adjusted as a consequence), and the replacement of _WIN32_WCE=0x0420 by _WIN32_WINNT=0x0501 is, of course, only for my machine. _WIN32_WINNT=0x0500 seems sufficient (it means that I require Windows 2000 at least for Evil), so I used it. I also added -lsecur32 to the link flags Check out Evil to see if my modifications fixed the compilation with MinGW. Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evil, svn trunk] autogen.sh failed on WinXP
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 Eina-dependent, here is a _really dirty_ patch to make Eina compile on WinXP. I added guards to prevent the eina_benchmark compilation when asked because gcc threw me an internal error in eina_benchmark_init()... The dirtiest part of the patch is declaring eina_mempool_register and eina_mempool_unregister with EAPI, because it helps passing the link stage. I don't know much about the differences between .dll and .so (there must me many), but gcc was not happy with these functions prototypes. I don't know exactly how to correct that, it's just a workaround. Added another small patch to make Evas GLEW engine compile again (need to include glew.h before gl.h). Regards, Lionel 2008/10/16 Vincent Torri [EMAIL PROTECTED]: 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 evil_pwd.c adjusted as a consequence), and the replacement of _WIN32_WCE=0x0420 by _WIN32_WINNT=0x0501 is, of course, only for my machine. _WIN32_WINNT=0x0500 seems sufficient (it means that I require Windows 2000 at least for Evil), so I used it. I also added -lsecur32 to the link flags Check out Evil to see if my modifications fixed the compilation with MinGW. Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evil, svn trunk] autogen.sh failed on WinXP
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... autoreconf does what other autogen.sh does. It's sufficient for my purposes Now that the EFL are Eina-dependent, here is a _really dirty_ patch to make Eina compile on WinXP. I added guards to prevent the eina_benchmark compilation when asked because gcc threw me an internal error in eina_benchmark_init()... The dirtiest part of the patch is declaring eina_mempool_register and eina_mempool_unregister with EAPI, because it helps passing the link stage. I don't know much about the differences between .dll and .so (there must me many), but gcc was not happy with these functions prototypes. I don't know exactly how to correct that, it's just a workaround. the patch is indeed dirty :) Try with my fixes in eina, now. It compiles fine with mingw32ce. I didn't try with mingw yet If you still have link problems with eina_mempool.c, please give the exact error message, it can help me. Added another small patch to make Evas GLEW engine compile again (need to include glew.h before gl.h). strange, I thought i have already committed that fix. Maybe i have forgotten that. I'll fix that later. Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ecore Path Groups broken?
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;
Ecore_List *testliste;
Ecore_Path_Group *testgruppe;
testgruppe = ecore_path_group_new();
ecore_path_group_add(testgruppe, /tmp);
testliste = ecore_list_new();
ecore_list_init(testliste);
testliste = ecore_path_group_available(testgruppe);
i = ecore_list_count(testliste);
printf(%d Entries\n, i);
return 0;
}
That's the result:
* Developer Warning * :
This program is calling:
ecore_list_count();
With the parameter:
list
being NULL. Please fix your program.
0 Entries
Thanks in advance,
thomasg
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Copyleft-style
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 be unique as the only successful GUI environment under a BSD-style license. I have used Evas as a component in a proof-of-concept for an embedded project using the eCos operating system. No patches or other information have been published yet, because the project is not yet released. But I do expect to have patches for EFL ready upon release in order to avoid the advertisement clause. Now, eCos is owned by the FSF and is licensed under the GPLv2 with a linking exception that makes it completely non-viral. This exception is more powerful than the LGPL, because the LGPL does require dynamic linking or the distribution of linkable object files and additional modification and reverse engineering rights. These obligations would infect a project that would otherwise just use a non-viral GPLv2 with linker exception. So I want to ask you to please consider keeping the core EFL components and non-optional dependencies under the existing BSD-style license or consider a non-viral copyleft like the GPLv2 with a linking exception in oder to keep the EFL usable with eCos and similar free embedded operating systems (FreeRTOS and RTEMS both use GPLv2 with linking exceptions too). Dynamic linking is not an option for deeply embedded operating systems. Often we dont even have a filesystem. Additionally I might mention that the BSD-style license of the EFL could mean that the EFL might technically be the only serious option for a free 3rd party GUI library on things like the iPhone. Dynamic linking does seem to exist on this platform but things like forced codesigning, bans on externally loadable code, and restrictions on reverse engineering and modification rights make the use of copylefted code questionable at best. MfG, Michael - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Copyleft-style
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. if we added the static linking exception - which imho would not violate the spirit of the LGPL, would this be good enough? (nb - if apple decide to place all these nasty nasty nasty restrictions on developers and applications - all the best to them, but i know i have zero interest in becoming part of that world as long as apple basically say you do just what we say, what we want, and if we don't like you we'll just ban your app from the platform because you may possibly compete with us or be the wrong shade of pink for steve jobs). i definitely buy the ecos (static linking) argument. i've explicitly cc'd all the AUTHORS for eina. do you guys agree to adding an ecos-style static linking exception (here it is for you guys): ...As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License. However the source code for this file must still be made available in accordance with section (3) of the GNU General Public License. This exception does not invalidate any other reasons why a work based on this file might be covered by the GNU General Public License 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 be unique as the only successful GUI environment under a BSD-style license. I have used Evas as a component in a proof-of-concept for an embedded project using the eCos operating system. No patches or other information have been published yet, because the project is not yet released. But I do expect to have patches for EFL ready upon release in order to avoid the advertisement clause. Now, eCos is owned by the FSF and is licensed under the GPLv2 with a linking exception that makes it completely non-viral. This exception is more powerful than the LGPL, because the LGPL does require dynamic linking or the distribution of linkable object files and additional modification and reverse engineering rights. These obligations would infect a project that would otherwise just use a non-viral GPLv2 with linker exception. So I want to ask you to please consider keeping the core EFL components and non-optional dependencies under the existing BSD-style license or consider a non-viral copyleft like the GPLv2 with a linking exception in oder to keep the EFL usable with eCos and similar free embedded operating systems (FreeRTOS and RTEMS both use GPLv2 with linking exceptions too). Dynamic linking is not an option for deeply embedded operating systems. Often we dont even have a filesystem. Additionally I might mention that the BSD-style license of the EFL could mean that the EFL might technically be the only serious option for a free 3rd party GUI library on things like the iPhone. Dynamic linking does seem to exist on this platform but things like forced codesigning, bans on externally loadable code, and restrictions on reverse engineering and modification rights make the use of copylefted code questionable at best. MfG, Michael - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ 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 the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Fix ecore_path_group_available
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
===
--- ecore_path.c(Revision 36702)
+++ ecore_path.c(Arbeitskopie)
@@ -148,7 +148,7 @@
* @ingroup Ecore_Path_Group
*/
EAPI Ecore_List *
-ecore_path_group_available(Ecore_Path_Group *group)
+ecore_path_group_available_get(Ecore_Path_Group *group)
{
Ecore_List *avail = NULL;
char *path;
@@ -179,18 +179,12 @@
while ((d = readdir(dir)) != NULL)
{
char ppath[PATH_MAX];
-char *ext;
/* char n[PATH_MAX];
int l;
*/
if (!strncmp(d-d_name, ., 1))
continue;
-ext = strrchr(d-d_name, '.');
-
-if (!ext || strncmp(ext, SHARED_LIB_SUFFIX,
sizeof(SHARED_LIB_SUFFIX)))
- continue;
-
snprintf(ppath, PATH_MAX, %s/%s, path, d-d_name);
stat(ppath, st);
Index: Ecore_Data.h
===
--- Ecore_Data.h(Revision 36702)
+++ Ecore_Data.h(Arbeitskopie)
@@ -331,7 +331,7 @@
/*
* Get a list of all the available files in a path set
*/
- EAPI Ecore_List * ecore_path_group_available(Ecore_Path_Group *group);
+ EAPI Ecore_List * ecore_path_group_available_get(Ecore_Path_Group *group);
typedef struct _ecore_plugin Ecore_Plugin;
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Copyleft-style
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 unfortunate as the EFL seems to be unique as the only successful GUI environment under a BSD-style license. I have used Evas as a component in a proof-of-concept for an embedded project using the eCos operating system. No patches or other information have been published yet, because the project is not yet released. But I do expect to have patches for EFL ready upon release in order to avoid the advertisement clause. Now, eCos is owned by the FSF and is licensed under the GPLv2 with a linking exception that makes it completely non-viral. This exception is more powerful than the LGPL, because the LGPL does require dynamic linking or the distribution of linkable object files and additional modification and reverse engineering rights. These obligations would infect a project that would otherwise just use a non-viral GPLv2 with linker exception. So I want to ask you to please consider keeping the core EFL components and non-optional dependencies under the existing BSD-style license or consider a non-viral copyleft like the GPLv2 with a linking exception in oder to keep the EFL usable with eCos and similar free embedded operating systems (FreeRTOS and RTEMS both use GPLv2 with linking exceptions too). Dynamic linking is not an option for deeply embedded operating systems. Often we dont even have a filesystem. Additionally I might mention that the BSD-style license of the EFL could mean that the EFL might technically be the only serious option for a free 3rd party GUI library on things like the iPhone. Dynamic linking does seem to exist on this platform but things like forced codesigning, bans on externally loadable code, and restrictions on reverse engineering and modification rights make the use of copylefted code questionable at best. Frankly, the thought of the bsd license making it the only 'serious option for free 3rd party gui..' for use on things like the iphone, is a travesty to me. While a (l)gplv2 is pefectly acceptable to me, as far as my contributions to this project I will make it very clear right now (in case I haven't earlier), that there will come a point in time, fairly soon in fact, where I will no longer contribute much more to bsd licensed code. Start providing for your family by becoming a paralegal. Click Now. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nffPOAI4otLSuXflQi5Avmh3rtd12h4NfmoCLJMP0AnVjgh/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Gentoo Ebuilds
-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 - iTReign \.''`. / [EMAIL PROTECTED] Developer / Systems Admin \ : :' : /[EMAIL PROTECTED] AIM: richohealey33 \ `. `' / [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] \ `- / [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj31FoACgkQLeTfO4yBSAehHQCdFPSGIKC3T/HY8L2gqT3ZjJl0 DbsAn2SU6w36jYRviOIgmSPd0nTe8lZq =MYio -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] learn efl
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 Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Copyleft-style
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 agreement essentially worthless. It is especially unfortunate as the EFL seems to be unique as the only successful GUI environment under a BSD-style license. it's not worthless, it still let you copy, modify and no need to redistribute all other pieces. You can even do that and remove the eina dependency and replace it with your own data libraries. You're also free to keep using the pre-eina version. I have used Evas as a component in a proof-of-concept for an embedded project using the eCos operating system. No patches or other information have been published yet, because the project is not yet released. But I do expect to have patches for EFL ready upon release in order to avoid the advertisement clause. note that while you don't release this to outer world you have no issues. I mean, if you use it inside your company for demo purposes, you can distribute code to yourselves and no problem. It's just a problem when you send it to third parties. Now, eCos is owned by the FSF and is licensed under the GPLv2 with a linking exception that makes it completely non-viral. This exception is more powerful than the LGPL, because the LGPL does require dynamic linking or the distribution of linkable object files and additional modification and reverse engineering rights. These obligations would infect a project that would otherwise just use a non-viral GPLv2 with linker exception. So I want to ask you to please consider keeping the core EFL components and non-optional dependencies under the existing BSD-style license or consider a non-viral copyleft like the GPLv2 with a linking exception in oder to keep the EFL usable with eCos and similar free embedded operating systems (FreeRTOS and RTEMS both use GPLv2 with linking exceptions too). Dynamic linking is not an option for deeply embedded operating systems. Often we dont even have a filesystem. I really doubt this will happen. I don't have much code in Eina so I'd agree with those that have and I guess they'll not like it, as you can read in the long thread. Basically because what matters is that we want to keep a healthy community, we want your code in exchange of ours. Why can you use my code and I can NOT use yours? That's the question, the problem and the license went in to solve that. If you give us your code, we give ours. Additionally I might mention that the BSD-style license of the EFL could mean that the EFL might technically be the only serious option for a free 3rd party GUI library on things like the iPhone. Dynamic linking does seem to exist on this platform but things like forced codesigning, bans on externally loadable code, and restrictions on reverse engineering and modification rights make the use of copylefted code questionable at best. I strongly disagree here. The problem is not about the library, dynamic linking or even licensing, it's about the platform. And I really doubt someone using EFL directly on iPhone, it have its own set of libraries, which is very complete and optimized by the way. We don't have that much apps to be ported, so not much point here. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gentoo Ebuilds
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 - they are the maintainers of the Gentoo overlay and ebuilds. The E team has nothing at all to do with them, and does not support them. Will Keaney uberpinguin signature.asc Description: OpenPGP digital signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gentoo Ebuilds
-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 want to double up. Rich You want to talk to vapier or gimpel - they are the maintainers of the Gentoo overlay and ebuilds. The E team has nothing at all to do with them, and does not support them. Will Keaney uberpinguin Thanks, I know E does not support them, but I figured a few E devs were probably aware of their existence/status. I'll get in touch with them Rich - -- Rich Healey - iTReign \.''`. / [EMAIL PROTECTED] Developer / Systems Admin \ : :' : /[EMAIL PROTECTED] AIM: richohealey33 \ `. `' / [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] \ `- / [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj335gACgkQLeTfO4yBSAc77wCfU6LOUjHjR16Iaj0XX0lHCYmW I6kAniv/Gjmd51jD5rNdwI2TKbgxcZpH =Nv9Z -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
