Re: [E-devel] improvements of configure
On Sun, 28 Oct 2007 13:41:38 +0100 (CET) Vincent Torri [EMAIL PROTECTED] babbled: Hey, The changes of edje's configure were done 3 weeks ago and it seems that no problem arises. I let one more week for last checks for packagers and other developpers. I'll do the changes next week end. nathan just fixed some awk fun where our awking didnt work for him - he fixed eet. just take note :) regards Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
Been a busy few weeks and I just got around to checking out and building again. I've built all of the libs required for EWL except for emotion on Solaris and things seem to be working well once those awk fixes were in place. On Nov 12, 2007 6:58 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sun, 28 Oct 2007 13:41:38 +0100 (CET) Vincent Torri [EMAIL PROTECTED] babbled: Hey, The changes of edje's configure were done 3 weeks ago and it seems that no problem arises. I let one more week for last checks for packagers and other developpers. I'll do the changes next week end. nathan just fixed some awk fun where our awking didnt work for him - he fixed eet. just take note :) regards Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Mon, 12 Nov 2007, Nathan Ingersoll wrote: Been a busy few weeks and I just got around to checking out and building again. I've built all of the libs required for EWL except for emotion on Solaris and things seem to be working well once those awk fixes were in place. ok, I'll do those changes Vincent On Nov 12, 2007 6:58 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sun, 28 Oct 2007 13:41:38 +0100 (CET) Vincent Torri [EMAIL PROTECTED] babbled: Hey, The changes of edje's configure were done 3 weeks ago and it seems that no problem arises. I let one more week for last checks for packagers and other developpers. I'll do the changes next week end. nathan just fixed some awk fun where our awking didnt work for him - he fixed eet. just take note :) regards Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Ce message a été vérifié par MailScanner pour des virus ou des polluriels et rien de suspect n'a été trouvé. Message délivré par le serveur de messagerie de l'Université d'Evry. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
Hey, I've begun to do the modifications of the configure.in and Makefile.am files. It's a very long process (lots of files and checks to do). For now, i've ported the libs that e17 uses (eet, evas, ecore, embryo, edje and e_dbus), in addition to efreet. I'll continue next week-end. Because of the current management of the libtool versioning, libecore_evas has now the version 0.9.9 and not 1.0.0. This imply that you must recompile all the libraries that depend on ecore_evas, otherwise you'll get an error (the app tried to load libecore_evas.so.1). If the path where your efl shared lib is stored in ld.so.conf*, run ldconfig as root after a lib is installed. Report any problem (apart the one above) in that thread. regards Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
Hey, The changes of edje's configure were done 3 weeks ago and it seems that no problem arises. I let one more week for last checks for packagers and other developpers. I'll do the changes next week end. regards Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Sun, 7 Oct 2007, Tilman Sauerbeck wrote:
Can we switch to this:
AC_INIT(package, version)
AC_CONFIG_SRCDIR([configure.in])
AM_INIT_AUTOMAKE([dist-bzip2])
instead? I believe that's the current way to initialize
autoconf/automake.
Tilman, here is a patch below. Is it sufficient for you ? If so, I'll
commit it
Vincent
Index: configure.in
===
RCS file: /cvs/e/e17/libs/edje/configure.in,v
retrieving revision 1.87
diff -u -r1.87 configure.in
--- configure.in7 Oct 2007 08:02:53 - 1.87
+++ configure.in7 Oct 2007 15:09:15 -
@@ -3,13 +3,14 @@
# get rid of that stupid cache mechanism
rm -f config.cache
-AC_INIT(configure.in)
+AC_INIT(edje, 0.5.0.041)
+AC_PREREQ(2.52)
+AC_CONFIG_SRCDIR(configure.in)
AC_CANONICAL_BUILD
AC_CANONICAL_HOST
AC_ISC_POSIX
-VER=0.5.0.041
-AM_INIT_AUTOMAKE(edje, $VER)
+AM_INIT_AUTOMAKE(1.6 dist-bzip2)
AM_CONFIG_HEADER(config.h)
AC_PROG_CC
@@ -22,10 +23,10 @@
define([AC_LIBTOOL_LANG_F77_CONFIG], [:])dnl
AC_PROG_LIBTOOL
-VMAJ=`echo $VER | awk -F . '{printf(%s, $1);}'`
-VMIN=`echo $VER | awk -F . '{printf(%s, $2);}'`
-VMIC=`echo $VER | awk -F . '{printf(%s, $3);}'`
-SNAP=`echo $VER | awk -F . '{printf(%s, $4);}'`
+VMAJ=`echo $PACKAGE_VERSION | awk -F . '{printf(%s, $1);}'`
+VMIN=`echo $PACKAGE_VERSION | awk -F . '{printf(%s, $2);}'`
+VMIC=`echo $PACKAGE_VERSION | awk -F . '{printf(%s, $3);}'`
+SNAP=`echo $PACKAGE_VERSION | awk -F . '{printf(%s, $4);}'`
version_info=`expr $VMAJ + $VMIN`:$VMIC:$VMIN
AC_SUBST(version_info)
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Sun, 7 Oct 2007 11:49:37 -0300 Gustavo Sverzut Barbieri
[EMAIL PROTECTED] babbled:
On 10/5/07, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote:
VER=1.2.3.045
...
AM_INIT_AUTOMAKE(edje, $VER)
...
VMAJ=`echo $VER | awk -F . '{printf(%s, $1);}'`
VMIN=`echo $VER | awk -F . '{printf(%s, $2);}'`
VMIC=`echo $VER | awk -F . '{printf(%s, $3);}'`
SNAP=`echo $VER | awk -F . '{printf(%s, $4);}'`
version_info=`expr $VMAJ + $VMIN`:$VMIC:$VMIN
AC_SUBST(version_info)
after I saw the commit it come to my mind:
VMAJ=`echo $VER | awk -F . '{printf(%s, $1);}'`
could use cut instead of the awk: echo $VER | cut -d. -f1
also, is it really $VMAJ + $VMIN? It may repeat easily, I'd go with
$VMAJ * 10 + $VMIN but I'm not sure if I'm correct.
no - it's vmaj+vmin
--
Gustavo Sverzut Barbieri
--
Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Sunday, 07 October 2007, at 11:39:42 (+0200), Tilman Sauerbeck wrote: Vincent Torri [2007-09-30 16:04]: Ideas ? remarks ? Can we switch to this: AC_INIT(package, version) AC_CONFIG_SRCDIR([configure.in]) AM_INIT_AUTOMAKE([dist-bzip2]) Except for the bzip2 part. Don't do that. gzip is the best choice. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- Quit playin' games with my heart before you tear us apart. I should've known from the start before you got into my heart. -- Backstreet Boys - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Sun, 7 Oct 2007, Michael Jennings wrote: On Sunday, 07 October 2007, at 11:39:42 (+0200), Tilman Sauerbeck wrote: Vincent Torri [2007-09-30 16:04]: Ideas ? remarks ? Can we switch to this: AC_INIT(package, version) AC_CONFIG_SRCDIR([configure.in]) AM_INIT_AUTOMAKE([dist-bzip2]) Except for the bzip2 part. Don't do that. gzip is the best choice. dist-bzip2 adds the bzip2 archive. The gzip archive is still built. Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
Vincent Torri [2007-09-30 16:04]: Ideas ? remarks ? Can we switch to this: AC_INIT(package, version) AC_CONFIG_SRCDIR([configure.in]) AM_INIT_AUTOMAKE([dist-bzip2]) instead? I believe that's the current way to initialize autoconf/automake. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgphi4whAUmxw.pgp Description: PGP signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Sun, 7 Oct 2007, Tilman Sauerbeck wrote: Vincent Torri [2007-09-30 16:04]: Ideas ? remarks ? Can we switch to this: AC_INIT(package, version) AC_CONFIG_SRCDIR([configure.in]) AM_INIT_AUTOMAKE([dist-bzip2]) instead? I believe that's the current way to initialize autoconf/automake. I'm not at all against that :) What is in our current configure.in (which should now be called configure.ac) is deprecated. the old use of AC_INIT and AM_INIT_AUTOMAKE is deprecated since autoconf 2.52 and automake 1.6 (in 2002) Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Sun, 7 Oct 2007 13:50:10 +0200 (CEST) Vincent Torri [EMAIL PROTECTED] babbled: On Sun, 7 Oct 2007, Tilman Sauerbeck wrote: Vincent Torri [2007-09-30 16:04]: Ideas ? remarks ? Can we switch to this: AC_INIT(package, version) AC_CONFIG_SRCDIR([configure.in]) AM_INIT_AUTOMAKE([dist-bzip2]) instead? I believe that's the current way to initialize autoconf/automake. I'm not at all against that :) What is in our current configure.in (which should now be called configure.ac) is deprecated. the old use of AC_INIT and AM_INIT_AUTOMAKE is deprecated since autoconf 2.52 and automake 1.6 (in 2002) lets play with edje then and get it settled until everyone is happy? Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On 10/5/07, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote:
VER=1.2.3.045
...
AM_INIT_AUTOMAKE(edje, $VER)
...
VMAJ=`echo $VER | awk -F . '{printf(%s, $1);}'`
VMIN=`echo $VER | awk -F . '{printf(%s, $2);}'`
VMIC=`echo $VER | awk -F . '{printf(%s, $3);}'`
SNAP=`echo $VER | awk -F . '{printf(%s, $4);}'`
version_info=`expr $VMAJ + $VMIN`:$VMIC:$VMIN
AC_SUBST(version_info)
after I saw the commit it come to my mind:
VMAJ=`echo $VER | awk -F . '{printf(%s, $1);}'`
could use cut instead of the awk: echo $VER | cut -d. -f1
also, is it really $VMAJ + $VMIN? It may repeat easily, I'd go with
$VMAJ * 10 + $VMIN but I'm not sure if I'm correct.
--
Gustavo Sverzut Barbieri
--
Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On 10/5/07, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: It's nice and clean, that's true -- but it's going to take discipline! indeed! absolutely. and i hope to maintain that discipline. until 1.0 i'm reserving the right to break anything and ignore the version - but from 1.0 on it's slave to the abi - we break abi - we go evas 2.0 or edje 3.0 etc. etc. and onwards as needed, and not because of some marketing desires to call it 2.0 or 3.0 etc. :) oh god... so I must break everything that I don't like now? :-D -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Sat, 6 Oct 2007 11:04:56 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On 10/5/07, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: It's nice and clean, that's true -- but it's going to take discipline! indeed! absolutely. and i hope to maintain that discipline. until 1.0 i'm reserving the right to break anything and ignore the version - but from 1.0 on it's slave to the abi - we break abi - we go evas 2.0 or edje 3.0 etc. etc. and onwards as needed, and not because of some marketing desires to call it 2.0 or 3.0 etc. :) oh god... so I must break everything that I don't like now? :-D well... unless you want to see evas go from 1.0 to 2.0 really fast! :) this is one reason i am holding off on 1.0 - to make sure we break all the things that need breaking now - early, so we can have a good gap between 1.0 and 2.0 -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Mon, 1 Oct 2007 20:07:41 +0200 Albin Tonnerre [EMAIL PROTECTED] babbled: While we're talking about configure... :) I'm part of the team which packages E for debian, and there's something in configure we'd really like to see changed (and of course we can provide patches): What we think is that when you enable a feature with --enable-whatever, and if the requirements of that feature are not found, configure should fail rather than silently disable it. The rationale for that is that, in our humble opinions, when you package for a distro, you want the stuff you enable to be actually present - thus, fail if not found rather than disable and tell nothing. As per discussion with raster on irc, I'm sure that some people may not want this behavior, and thus thought we could possibly add a --whatever-name-we-could-call-it , which implements such behavior (and let the default as it is) Thoughts ? (hint: 'this is your distro's problem is not a valid answer) we like our soft fallback so our build scripts can blindly run and adapt to system features :) this is a difference in philosophy i guess. do you take an error as a hard error - or a soft error. we go for soft. that's because we're all warm and fuzzy at heart! :) Regards, Albin Tonnerre On Sun, Sep 30, 2007 at 03:01:32PM -0700, Michael Jennings wrote : On Sunday, 30 September 2007, at 16:04:54 (+0200), Vincent Torri wrote: Since I try to port the efl on windows, I've run into some problems with autofoo (strange, isn't it ?). I've looked a bit at autoconf and libtool doc, and I think that configure.in scripts can be improved a bit. Here is what I propose. Feel free to tell me if my proposals are not correct. ... Ideas ? remarks ? Most of that sounds fine, but why not provide us with a sample configure.in with examples of all 5 changes made to it so we can get a more concrete idea of what you're wanting to do? Then if people have any specific objections, they're easier to note. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- I am the one and only; nobody I'd rather be. I am the one and only. You can't take that away from me. -- Chesney Hawkes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Albin Tonnerre, aka Lutin - Search a little longer, travel a little further -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Tue, 2 Oct 2007 18:31:34 +0200 (CEST) Vincent Torri [EMAIL PROTECTED] babbled: ok- looking at the patch gives me meat to chew on :) overall this looks good. i'm a little dubious of the whole libtool version thing - i actually HATE it. i'd prefer the libtool revision/version/whatever stuff is sourced/generated from the package itself (eg 0.5.0 for edje) and we will increment this ONE version info only. i know what major and minor versions mean - most developers do/should so i'd rather have a single version tag there if possible - all the space used up by the libtool scheme comments could work on some script mojo to work out the libtool version magic from the package version. i really want to keep them consistent at all times if possible. thats my only issue - otherwise it seems ok to me. anyone else want to chime in? On Sun, 30 Sep 2007, Michael Jennings wrote: Most of that sounds fine, but why not provide us with a sample configure.in with examples of all 5 changes made to it so we can get a more concrete idea of what you're wanting to do? Then if people have any specific objections, they're easier to note. I've attached a patch for (for instance) edje, that shows the modifications I want to do. I've put the libtool doc about its versioning, but it's not necessary to include it in configure.in. so, what is good ? what is not correct ? Vincent -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Fri, 5 Oct 2007 13:21:27 +0200 Albin Tonnerre [EMAIL PROTECTED] babbled: On Fri, Oct 05, 2007 at 03:10:08PM +0900, Carsten Haitzler wrote : On Mon, 1 Oct 2007 20:07:41 +0200 Albin Tonnerre [EMAIL PROTECTED] babbled: While we're talking about configure... :) I'm part of the team which packages E for debian, and there's something in configure we'd really like to see changed (and of course we can provide patches): What we think is that when you enable a feature with --enable-whatever, and if the requirements of that feature are not found, configure should fail rather than silently disable it. The rationale for that is that, in our humble opinions, when you package for a distro, you want the stuff you enable to be actually present - thus, fail if not found rather than disable and tell nothing. As per discussion with raster on irc, I'm sure that some people may not want this behavior, and thus thought we could possibly add a --whatever-name-we-could-call-it , which implements such behavior (and let the default as it is) Thoughts ? (hint: 'this is your distro's problem is not a valid answer) we like our soft fallback so our build scripts can blindly run and adapt to system features :) this is a difference in philosophy i guess. do you take an error as a hard error - or a soft error. we go for soft. that's because we're all warm and fuzzy at heart! :) That's why my proposal wasn't to make such a behavior a default, but an alternative :) we could - with a --enable-strict-dependencies or something... but then we'd have to go do something... got patches? :) (me - i've only got milk). Regards Regards, Albin Tonnerre On Sun, Sep 30, 2007 at 03:01:32PM -0700, Michael Jennings wrote : On Sunday, 30 September 2007, at 16:04:54 (+0200), Vincent Torri wrote: Since I try to port the efl on windows, I've run into some problems with autofoo (strange, isn't it ?). I've looked a bit at autoconf and libtool doc, and I think that configure.in scripts can be improved a bit. Here is what I propose. Feel free to tell me if my proposals are not correct. ... Ideas ? remarks ? Most of that sounds fine, but why not provide us with a sample configure.in with examples of all 5 changes made to it so we can get a more concrete idea of what you're wanting to do? Then if people have any specific objections, they're easier to note. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- I am the one and only; nobody I'd rather be. I am the one and only. You can't take that away from me. -- Chesney Hawkes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Albin Tonnerre, aka Lutin - Search a little longer, travel a little further -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) -- Albin Tonnerre, aka Lutin - Search a little longer, travel a little further -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Friday, 05 October 2007, at 15:17:19 (+0900), Carsten Haitzler wrote: ok- looking at the patch gives me meat to chew on :) overall this looks good. i'm a little dubious of the whole libtool version thing - i actually HATE it. i'd prefer the libtool revision/version/whatever stuff is sourced/generated from the package itself (eg 0.5.0 for edje) and we will increment this ONE version info only. i know what major and minor versions mean - most developers do/should so i'd rather have a single version tag there if possible - all the space used up by the libtool scheme comments could work on some script mojo to work out the libtool version magic from the package version. i really want to keep them consistent at all times if possible. thats my only issue - otherwise it seems ok to me. The problem is, this is simply not the way shared library versioning works. The dynamic linker has specific ideas about how to tell which shared libraries will work with which executables based on the soversion, and your way of thinking about it violates that. There is absolutely no reason why, for example, an app linked against Imlib2 1.3.0 cannot continue to work (albeit improved) with 1.3.1 unless the ABI changes. That's why if you properly follow the libtool guidelines previously mentioned, you'll have to rebuild your binaries if, and only if, the shared library interface actually changes. If, however, you have a shared library that really DOES need to be tied to a specific version of the package (like libEterm is tied to each version of Eterm, for obvious reasons), instead of using -version-info X:Y:Z use -release $(VERSION). That is the accepted libtool way of doing what you want without wreaking havoc on poor defenseless ld.so. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- But I dumped her. My motto is, 'Get out before they go down.' That is so *not* my motto. -- Monica Geller and Joey Tribbiani, Friends - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Fri, 5 Oct 2007 09:35:31 -0700 Michael Jennings [EMAIL PROTECTED] babbled: On Friday, 05 October 2007, at 15:17:19 (+0900), Carsten Haitzler wrote: ok- looking at the patch gives me meat to chew on :) overall this looks good. i'm a little dubious of the whole libtool version thing - i actually HATE it. i'd prefer the libtool revision/version/whatever stuff is sourced/generated from the package itself (eg 0.5.0 for edje) and we will increment this ONE version info only. i know what major and minor versions mean - most developers do/should so i'd rather have a single version tag there if possible - all the space used up by the libtool scheme comments could work on some script mojo to work out the libtool version magic from the package version. i really want to keep them consistent at all times if possible. thats my only issue - otherwise it seems ok to me. The problem is, this is simply not the way shared library versioning works. The dynamic linker has specific ideas about how to tell which shared libraries will work with which executables based on the soversion, and your way of thinking about it violates that. There is absolutely no reason why, for example, an app linked against Imlib2 1.3.0 cannot continue to work (albeit improved) with 1.3.1 unless the ABI changes. That's why if you properly follow the libtool guidelines previously mentioned, you'll have to rebuild your binaries if, and only if, the shared library interface actually changes. i know how it works :) i just don't want to work with libtool's abortion of a versioning system. i want to do it the old fashioned way. .so major version changes == abi break. old calls removed or changed abi or functionality. minor version == calls added, but no functionality changes in existing calls. micro == no calls added or removed, no functionality changes, just internal fixes/improvements. i want to keep the version of the package the same as the lib .so version. it's cleaner and nicer. unless we go screw things up and decide to name release versions without thought to compatibility - then we need to do the below, but if we do things right, we don't need to. if i break abi i will cal the package evas-2.0.0.tar.gz (or whatever) as opposed to 1.0.0. i will make the package release # the same as the lib .so version as needed. If, however, you have a shared library that really DOES need to be tied to a specific version of the package (like libEterm is tied to each version of Eterm, for obvious reasons), instead of using -version-info X:Y:Z use -release $(VERSION). That is the accepted libtool way of doing what you want without wreaking havoc on poor defenseless ld.so. nooo - i don't want to make a new .so for each version with -release. there is no need to put the link version directly in the library name. i ONLY need to do this if i plan on having 2 or more versions of the lib around AND application needing to explicitly link at compile time to either a newer or older version. eg. gtk2 vs gtk1. (at that point - mayaswell have new lib names too as the version is now part of the lib name anyway as far as ld.so etc. are concerned). Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- But I dumped her. My motto is, 'Get out before they go down.' That is so *not* my motto. -- Monica Geller and Joey Tribbiani, Friends - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Saturday, 06 October 2007, at 01:50:06 (+0900), Carsten Haitzler wrote: i know how it works :) i just don't want to work with libtool's abortion of a versioning system. i want to do it the old fashioned way. .so major version changes == abi break. old calls removed or changed abi or functionality. minor version == calls added, but no functionality changes in existing calls. micro == no calls added or removed, no functionality changes, just internal fixes/improvements. That's really how it works already, or at least pretty close. The middle number is micro, so if anything at all changes, you bump the middle number. If you add new API calls, you increment BOTH the first and third number; this will keep the major soversion the same and bump the minor version. If you remove any API calls, set the last number to 0 after incrementing the first number -- this will bump the major soversion. Is that what you were saying? If so, I totally missed it. Too early I guess. :) i want to keep the version of the package the same as the lib .so version. it's cleaner and nicer. unless we go screw things up and decide to name release versions without thought to compatibility - then we need to do the below, but if we do things right, we don't need to. if i break abi i will cal the package evas-2.0.0.tar.gz (or whatever) as opposed to 1.0.0. i will make the package release # the same as the lib .so version as needed. That will work as long as everyone understands that the *package* version is now a slave to the *library* version, not the other way around. We have to make sure the package is versioned based on the ABI, not just force the soversion to match whatever arbitrary package version we pick. It's nice and clean, that's true -- but it's going to take discipline! nooo - i don't want to make a new .so for each version with -release. there is no need to put the link version directly in the library name. i ONLY need to do this if i plan on having 2 or more versions of the lib around AND application needing to explicitly link at compile time to either a newer or older version. eg. gtk2 vs gtk1. (at that point - mayaswell have new lib names too as the version is now part of the lib name anyway as far as ld.so etc. are concerned). Right, but it does give one the ability to use the package version when building the library without breaking soversioning. But if you're wanting to keep them in sync by focusing on the library version, not the package version, that's fine. It's just not the way most projects seem to think these days. :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- The world isn't run by weapons any more, or energy, or money. It's run by little 1's and 0's, little bits of data. It's all just electrons! There's a war out there, old friend -- a world war, and it's not about who's got the most bullets. It's about who controls the information: what we see and hear, how we work, what we think. It's all about the information. -- Cosmo (Ben Kingsley), Sneakers - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Fri, 5 Oct 2007 10:19:59 -0700 Michael Jennings [EMAIL PROTECTED] babbled:
On Saturday, 06 October 2007, at 01:50:06 (+0900),
Carsten Haitzler wrote:
i know how it works :) i just don't want to work with libtool's
abortion of a versioning system. i want to do it the old fashioned
way. .so major version changes == abi break. old calls removed or
changed abi or functionality. minor version == calls added, but no
functionality changes in existing calls. micro == no calls added or
removed, no functionality changes, just internal fixes/improvements.
That's really how it works already, or at least pretty close. The
middle number is micro, so if anything at all changes, you bump the
middle number. If you add new API calls, you increment BOTH the first
and third number; this will keep the major soversion the same and bump
the minor version. If you remove any API calls, set the last number
to 0 after incrementing the first number -- this will bump the major
soversion.
Is that what you were saying? If so, I totally missed it. Too early
I guess. :)
yeah - that's what i;m saying. the fact that it has a different numbering
scheme just is painful - have to maintain 2 sets of numbers (yes - the forumla
is what you say to convert from package version to .so version going via
version-info). i'm only saying that we have a lump of shell script there
instead of a big wad of comments to do that for us. i.e. (in extreme ugliness
and a quick 1 minute job in an email:
VER=1.2.3.045
...
AM_INIT_AUTOMAKE(edje, $VER)
...
VMAJ=`echo $VER | awk -F . '{printf(%s, $1);}'`
VMIN=`echo $VER | awk -F . '{printf(%s, $2);}'`
VMIC=`echo $VER | awk -F . '{printf(%s, $3);}'`
SNAP=`echo $VER | awk -F . '{printf(%s, $4);}'`
version_info=`expr $VMAJ + $VMIN`:$VMIC:$VMIN
AC_SUBST(version_info)
etc.
i.e. - just a lump of shell logic that takes the package version and creates
a .so version from it that matches by appeasing the libtool version info gods
and sacrificing a little math to them.
a slight problem here is that the .so version for evas is already 1.0.0 so we
are going to make an exception until release (need to check other libs too).
i want to keep the version of the package the same as the lib .so
version. it's cleaner and nicer. unless we go screw things up and
decide to name release versions without thought to compatibility -
then we need to do the below, but if we do things right, we don't
need to. if i break abi i will cal the package evas-2.0.0.tar.gz (or
whatever) as opposed to 1.0.0. i will make the package release # the
same as the lib .so version as needed.
That will work as long as everyone understands that the *package*
version is now a slave to the *library* version, not the other way
around. We have to make sure the package is versioned based on the
ABI, not just force the soversion to match whatever arbitrary package
version we pick.
It's nice and clean, that's true -- but it's going to take discipline!
indeed! absolutely. and i hope to maintain that discipline. until 1.0 i'm
reserving the right to break anything and ignore the version - but from 1.0 on
it's slave to the abi - we break abi - we go evas 2.0 or edje 3.0 etc. etc.
and onwards as needed, and not because of some marketing desires to call it 2.0
or 3.0 etc. :)
nooo - i don't want to make a new .so for each version with
-release. there is no need to put the link version directly in the
library name. i ONLY need to do this if i plan on having 2 or more
versions of the lib around AND application needing to explicitly
link at compile time to either a newer or older version. eg. gtk2 vs
gtk1. (at that point - mayaswell have new lib names too as the
version is now part of the lib name anyway as far as ld.so etc. are
concerned).
Right, but it does give one the ability to use the package version
when building the library without breaking soversioning. But if
you're wanting to keep them in sync by focusing on the library
version, not the package version, that's fine. It's just not the way
most projects seem to think these days. :)
yeah - i know :) i'm trying to avoid that though by wanting to use .so
versioning as much as we can without juping into package versioning. that is a
work around after a project has been around long enough to require
compatibility back to older apps (gtk1 vs gtk2 for example) and allowing
development on older branches of the code etc. to continue. i hope not to get
into that boat :)
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED]
Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org)
---
The world isn't run by weapons any more, or energy, or money. It's
run by little 1's and 0's, little bits of data. It's all just
electrons! There's a war out there, old friend -- a world war, and
it's not about who's got the
Re: [E-devel] improvements of configure
On Sun, 30 Sep 2007, Michael Jennings wrote:
Most of that sounds fine, but why not provide us with a sample
configure.in with examples of all 5 changes made to it so we can get a
more concrete idea of what you're wanting to do? Then if people have
any specific objections, they're easier to note.
I've attached a patch for (for instance) edje, that shows the
modifications I want to do.
I've put the libtool doc about its versioning, but it's not necessary to
include it in configure.in.
so, what is good ? what is not correct ?
VincentIndex: configure.in
===
RCS file: /cvs/e/e17/libs/edje/configure.in,v
retrieving revision 1.86
diff -u -r1.86 configure.in
--- configure.in8 Sep 2007 18:36:22 - 1.86
+++ configure.in2 Oct 2007 16:25:13 -
@@ -15,8 +15,37 @@
AM_PROG_CC_C_O
AC_HEADER_STDC
AC_C_CONST
-AM_ENABLE_SHARED
-AM_PROG_LIBTOOL
+AC_LIBTOOL_WIN32_DLL
+define([AC_LIBTOOL_LANG_CXX_CONFIG], [:])dnl
+define([AC_LIBTOOL_LANG_F77_CONFIG], [:])dnl
+AC_PROG_LIBTOOL
+
+dnl From GNU Libtoool 1.2 manual:
+dnl 1. Start with version information of `0:0:0' for each libtool library.
+dnl
+dnl 2. Update the version information only immediately before a public
+dnl release of your software. More frequent updates are unnecessary,
+dnl and only guarantee that the current interface number gets larger
+dnl faster.
+dnl
+dnl 3. If the library source code has changed at all since the last
+dnl update, then increment REVISION (`C:R:A' becomes `C:R+1:A').
+dnl
+dnl 4. If any interfaces have been added, removed, or changed since the
+dnl last update, increment CURRENT, and set REVISION to 0.
+dnl
+dnl 5. If any interfaces have been added since the last public release,
+dnl then increment AGE.
+dnl
+dnl 6. If any interfaces have been removed since the last public release,
+dnl then set AGE to 0.
+
+INTERFACE_CURRENT=5
+INTERFACE_REVISION=0
+INTERFACE_AGE=5
+version_info=${INTERFACE_CURRENT}:${INTERFACE_REVISION}:${INTERFACE_AGE}
+AC_SUBST(version_info)
+
AC_FUNC_ALLOCA
create_shared_lib=
@@ -51,35 +80,6 @@
AC_SUBST(fnmatch_libs)
-if test x${bindir} = 'xNONE'; then
- if test x${prefix} = xNONE; then
-PACKAGE_BIN_DIR=${ac_default_prefix}/bin
- else
-PACKAGE_BIN_DIR=${prefix}/bin
- fi
-else
- PACKAGE_BIN_DIR=${bindir}
-fi
-AC_SUBST(PACKAGE_BIN_DIR)
-
-if test x${libdir} = 'xNONE'; then
- if test x${prefix} = xNONE; then
-PACKAGE_LIB_DIR=${ac_default_prefix}/lib
- else
-PACKAGE_LIB_DIR=${prefix}/lib
- fi
-else
- PACKAGE_LIB_DIR=${libdir}
-fi
-AC_SUBST(PACKAGE_LIB_DIR)
-
-if test x${prefix} = xNONE; then
- PACKAGE_DATA_DIR=${ac_default_prefix}/share/${PACKAGE}
-else
- PACKAGE_DATA_DIR=${prefix}/share/${PACKAGE}
-fi
-AC_SUBST(PACKAGE_DATA_DIR)
-
AC_MSG_CHECKING(whether to build edje_cc)
have_edje_cc=yes
AC_ARG_ENABLE(edje-cc, [ --disable-edje-cc disable building of edje_cc
], [
Index: src/bin/Makefile.am
===
RCS file: /cvs/e/e17/libs/edje/src/bin/Makefile.am,v
retrieving revision 1.40
diff -u -r1.40 Makefile.am
--- src/bin/Makefile.am 8 Sep 2007 18:34:40 - 1.40
+++ src/bin/Makefile.am 2 Oct 2007 16:25:13 -
@@ -5,9 +5,9 @@
-I$(top_srcdir)/bin \
-I$(top_srcdir)/src/lib \
@EDJE_CFLAGS@ \
--DPACKAGE_BIN_DIR=\@[EMAIL PROTECTED] \
--DPACKAGE_LIB_DIR=\@[EMAIL PROTECTED] \
--DPACKAGE_DATA_DIR=\@[EMAIL PROTECTED]
+-DPACKAGE_BIN_DIR=\$(bindir)\ \
+-DPACKAGE_LIB_DIR=\$(libdir)\ \
+-DPACKAGE_DATA_DIR=\$(datadir)/$(PACKAGE)\
bin_SCRIPTS = \
@EDJE_RECC_PRG@
Index: src/lib/Makefile.am
===
RCS file: /cvs/e/e17/libs/edje/src/lib/Makefile.am,v
retrieving revision 1.35
diff -u -r1.35 Makefile.am
--- src/lib/Makefile.am 26 Aug 2007 12:54:51 - 1.35
+++ src/lib/Makefile.am 2 Oct 2007 16:25:13 -
@@ -39,5 +39,5 @@
libedje_la_LIBADD = -lm @EDJE_LIBS@ @fnmatch_libs@
libedje_la_CPPFLAGS =
libedje_la_DEPENDENCIES = $(top_builddir)/config.h
-libedje_la_LDFLAGS = @create_shared_lib@ -version-info 5:0:5
+libedje_la_LDFLAGS = @create_shared_lib@ -version-info @version_info@
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Tuesday, 02 October 2007, at 18:31:34 (+0200), Vincent Torri wrote: I've attached a patch for (for instance) edje, that shows the modifications I want to do. I've put the libtool doc about its versioning, but it's not necessary to include it in configure.in. so, what is good ? what is not correct ? 100% kickass. Good work, Vincent! :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- I don't kill flies but I like to mess with their minds. I hold them above globes. They freak out and yell, 'Whoa, I'm way too high!' -- Bruce Baum - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
While we're talking about configure... :) I'm part of the team which packages E for debian, and there's something in configure we'd really like to see changed (and of course we can provide patches): What we think is that when you enable a feature with --enable-whatever, and if the requirements of that feature are not found, configure should fail rather than silently disable it. The rationale for that is that, in our humble opinions, when you package for a distro, you want the stuff you enable to be actually present - thus, fail if not found rather than disable and tell nothing. As per discussion with raster on irc, I'm sure that some people may not want this behavior, and thus thought we could possibly add a --whatever-name-we-could-call-it , which implements such behavior (and let the default as it is) Thoughts ? (hint: 'this is your distro's problem is not a valid answer) Regards, Albin Tonnerre On Sun, Sep 30, 2007 at 03:01:32PM -0700, Michael Jennings wrote : On Sunday, 30 September 2007, at 16:04:54 (+0200), Vincent Torri wrote: Since I try to port the efl on windows, I've run into some problems with autofoo (strange, isn't it ?). I've looked a bit at autoconf and libtool doc, and I think that configure.in scripts can be improved a bit. Here is what I propose. Feel free to tell me if my proposals are not correct. ... Ideas ? remarks ? Most of that sounds fine, but why not provide us with a sample configure.in with examples of all 5 changes made to it so we can get a more concrete idea of what you're wanting to do? Then if people have any specific objections, they're easier to note. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- I am the one and only; nobody I'd rather be. I am the one and only. You can't take that away from me. -- Chesney Hawkes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Albin Tonnerre, aka Lutin - Search a little longer, travel a little further signature.asc Description: Digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
On Monday, 01 October 2007, at 20:07:41 (+0200), Albin Tonnerre wrote: Thoughts ? (hint: 'this is your distro's problem is not a valid answer) Not only is it valid, it's correct. It is the responsibility of the build system to correctly process dependencies (whether hard or soft) to make sure that the build environment contains all packages requested for the build. The packaging should insure that failures due to missing prerequisites either occur or do not occur, according to the policies of the particular distribution. Relying on the upstream package provider to ensure compliance with Debian packaging standards is entirely the wrong approach. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- I try to smile so the hurt won't show, tell everybody I was glad to see you go. But the tears just won't go away. Loneliness found me; looks like it's here to stay. -- Expose, I'll Never Get Over You (Getting Over Me) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
