On Wed, 18 Feb 2004 03:27:44 +0100 Michel Briand <[EMAIL PROTECTED]> babbled:
> Hello EveryOne :-)
>
> I think one of our priorities should be to clean up building system. I'm
> used to Linux building environement such as automake/autoconf but as
> stated by Vincent and Mike another build system is probably a better choice.
let me say 3 things.
1. from a developers standpoint autoSPLAT (auto*/libtool) really are a PAIN IN
THE ARSE. they keep changing, become incompatible with each other or non
backwards compatible almost every second release of any one of them. They are a
PAIN to learn and use.
2. there are no feasibly equivalent alternatives. there's pmake, jam, cmake, but
they don't do all auto* do. lets NOT speak of porting our build trees to go use
another build system as well! thats a tonne of work that i am sure none of us is
keen to do.
3. autoSPLAT is an issue for DEVELOPERS ONLY. if you develop E code
(write/modify/patch) it's an issue. if you run a source based dist or get the
source as a user it is NOT AN ISSUE. a developer goes and runs:
make distcheck
that BUILDS a distribution tarball with a configure script that a user simply
goes:
./configure
make
make install
thats it. they do not need autoconf, automake, libtool or any other autoSPLAT
tool even installed. they don't need to know or care. that is one good bit about
autoSPLAT. autoSPLAT tools and versions are ONLY an issue for people getting E
form CVS. CVS is a DEVELOPER tool. as a developer you arrange to be in sync with
the autotools needed to build your project - you learn what is needed. it comes
with the territory. you cant be a soccer player and unable to kick the ball. you
learn to do it. thus autoSPALT is irrelevant for the average user. if a source
base distro chooses to expose the pain of autoSPLAT to end users its the
distro's problem, no ours. i will not lift a finger to help this situation as it
is one not of our creation nor our responsibility. we have much more important
fish to fry.
> Vincent pointed us to PMK.
> Mike to CMAKE.
>
> I've some experiences with uClibc build environment and I like their
> curses based configuration tool that looks like Kernel configuration
> tool. It's simple and straitforward.
>
> <IMHO>
> Libtool is a pain because as I'm running a source based distro I found
> that you can't trick the use of CFLAGS/LDFLAGS and CC (for distcc for
> example) with libtool. It builds deps scripts and the like and you are
> forced to reconfigure every time :-(. Libtool should be avoided as much
> as possible.
> </IMHO>
absolutely you can! i use ccache and have used distcc many times with the e
codebase. i found ccache will give much better performance that distcc for me,
so gave up - i've used distcc and ccache in combination too!
> Perhaps EFL dependencies should be clearly documented.
i did a handy dependency graph:
http://www.rasterman.com/files/efl2.png
:) most projects have their dependencies clearly documented in their respective
README's and docs.
> Then we can make a global build script.
this is on the "somewhere near e17 release" list - ie once the wm is settling
down to being stable and really is just being tweaked, patched and minorly
improved before release. provide a "meta tarball" that can even include all the
libs and projects and have a master makefile/configure script. autoSPALT can do
this. we are in no hurry to do this yet as it makes independent development
harder and right now thats more important.
> This global build script could allows the user to select PREFIX, BUILD,
> CFLAGS and the like and then propagates them to each directory build
> script. It could also present a features list to select wich lib/app you
> want.
easy. just makes management harder.
> This approach can permit a smooth migration from auto* and libtool to a
> more simple/robust system in wich the global script configure Makefiles,
> perhaps with cmake or pmk...
personally somewhere about this time i was thinking about rolling our own "Red
carpet" like installer tool - that will take appropriate source files and build
them on your box, depending what distro ensure u have the appropriate required
packages. it'd be a stop-gap measure till distros include E packages and would
also be a good universal installer regardless of distro, OS etc. this work can
be punted off until closer to release, but anyone wanting to start on such a
tool is welcome to.
anyway - the gist of this mail: autoSPLAT may suck - yes, but i fail to see any
tool that is significantly better or even equivalent to justify the PAIN of a
move to it. autoSPLAT can do what you want. i think u need to give it some more
time, love and attention :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 (数田) [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
