David Seikel wrote: > On Thu, 15 Feb 2007 09:24:14 +0900 Carsten Haitzler (The Rasterman) > <[EMAIL PROTECTED]> wrote: > >> the real problem is introducing cvs as a build and rebuild dep (which >> it never was before - cvs was entirely divorced and separate from >> build file creation - which allowed us to divorce CMS from coding if >> we ever wanted to). sure it'd need the cvs command - but it's >> sneaking in. it feels very unclean to me. i see the logic of using >> cvs as a compression scheme for multiple versions of gettext, but >> where autofoo used to be basic unix utils + m4 now is stealing away >> with cvs too. we are forever changing out autofoo - mostly for the >> next user X who uses gentoo or some bleeding edge distro who updates >> to latest bleeding edge autofoo X and breaks something. > We are already far from basic unix utils + m4 as autotools require perl. Adding cvs is just another drop in the ocean. If adding cvs resolves just a few of the issues there have been over time that is in my opinion a price worth paying.
> Another major problem, at least as far as I'm concerned, is that > autotools is forever trying to sneak in GPL licenses and FSF > copyrights. I've pointed this out to Marc-Andre in private emails, > and I probably mentioned this the last time around. E17 is BSD licensed > and copyright Raster + friends, but the use of autopoint generates files > that claim FSF copyright over parts of E17. > I don't think this is true, please correct me if I'm wrong. autopoint will copy in ABOUT-NLS which contains information about the gettext package, including licensensing, but it does not sneak in anything or otherwise impose licensing that isn't already implied by using gettext in the first place. It can be avoided to include ABOUT-NLS in the distribution tarball by removing it after running autopoint and specifying AUTOMAKE_OPTIONS = foreign in the top-level Makefile.am (meaning "this is not a GNU project"). If you don't have a COPYING, a GPL one will be copied in somewhere along the auto-line (not sure if it has anything to do with gettext, and AUTOMAKE_OPTIONS = foreign suppresses this) but it will not replace/modify an existing one, which you of course should have to begin with. gettextize, on the other hand, is a tool that can assist you making various changes to the autotool files to get gettext set up for the package. gettextize will mess around all over the place, add stuff to ChangeLog and po/ChangeLog and whatnot, and should *not* be run from autogen.sh. > Other projects that use autotools work quite happily by stating the > version of autotools required. Since autotools is a developer tool > that is not normally used by ordinary users (even if they are compiling > from source) specifying specific versions is quite valid, it keeps all > the developers on the same page, and reduces the complexities of > supporting various systems. So we can stop wasting time supporting the > latest bleeding edge autotools, stick with what has worked for years, > and get on with E coding. > If building E requires specific autotool versions, some documentation of which they are would be nice (wiki?). Should those be coded into all the autogen.sh's? Otherwise maybe provide some tips about how to set up your environment to use the correct autotool versions (wiki?). Downgrading say automake-1.10 to automake-1.9.6 is in my opinion not an option as non-e packages may require 1.10. Or is the message that if I'm too stupid to figure it all out by myself I should go play elsewhere? But I don't. I want E. I goto get-e, edevelop, #e, the mailing lists where you will waste your time giving me bad advice wasting my time. /Kim ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
