[e-users] Really Need Proper Build system for Enlightenment ( E17 )
Suresh Kumar
Year back I came to know about Enlightenment project while looking for
something in the web, I got inspired by the flexibility and like to
continuously use E17 as my primary window manager. So far so good and I use
Easy_17.sh scripts to build the code and install. now a days it is really
hard if some folders moved / something goes wrong. Besides I didn't see any
update happening to that script. I do modify the scripts to make it build
the e17 code but most of the people interested in final output then going
spending their time on making changes and make it build.
Recently I have notices that *Language* module moved to Broken and easy_17
script loops there for hours and I made a change to skip it and now again
stop at *exquisite/m4 *here and searching for this file. I can make that
change but if this is keep happening it would be better to provide build
script with source code and how we know that Language module is back and
working.
My request would be that E17 team should really focus on build and
configuration as one system for final users at least anyone can download
and install without trouble. It does not mean that I am not saying to
remove current flexibility where user can build each module standalone but
it would be great if we can build as one system just like easy_17.sh but
more stable and updating with every changes of e17 source code if possible
nightly build should use it so that update conforms that build scripts is
update to date.
Note : Normally I run with FULL option to get all the functionalities.
I came across CMAKE project and lot of open source tools moving towards to
this build system. But its up to Enlightenment team to come up with best
system for both ( Current and future )
--
-Regards,
Suresh
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
enlightenment-users mailing list
enlighten...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Jeff Hoogland
easier to compile things? Compiling software is rarely a simple process
(although the easy_e17 script does a pretty good job of it). If you are
looking for an "easier" way to get to the Enlightenment desktop I would
recommend giving Bodhi Linux, Macpup or even Ubuntu with the E PPA enabled
a try - that way you don't have to compile things.
On Sat, Mar 24, 2012 at 8:37 PM, Suresh Kumar <unique...@gmail.com>wrote:
> Hello All,
>
> Year back I came to know about Enlightenment project while looking for
> something in the web, I got inspired by the flexibility and like to
> continuously use E17 as my primary window manager. So far so good and I use
> Easy_17.sh scripts to build the code and install. now a days it is really
> hard if some folders moved / something goes wrong. Besides I didn't see any
> update happening to that script. I do modify the scripts to make it build
> the e17 code but most of the people interested in final output then going
> spending their time on making changes and mate it build.
--
~Jeff Hoogland <http://jeffhoogland.com/>
Thoughts on Technology <http://jeffhoogland.blogspot.com/>, Tech Blog
Bodhi Linux <http://bodhilinux.com/>, Enlightenment for your Desktop
Suresh Kumar
Sorry for the confusion which I have caused, Actually I used easy_17
script to install on my fedora 16 desktop and it was worked great.
Recently I used same script to update exisitng e17 code to get latest
functionalities and it keep looping on svn update to locate Language folder
from E-MODULES-EXTRA<http://trac.enlightenment.org/e/browser/trunk/E-MODULES-EXTRA>module.
By the way, I found *Makefile.linux *script under truck folder which I did
not see ( My apologies).
So, Can I use this make file as an alternate for easy_17 script. If so I
think, I got it what I was asking for ? Please suggest.
Thanks in advance.
-Regards
Suresh
Suresh Kumar
trunk folder.
Here is path to locate the script in svn :
http://svn.enlightenment.org/svn/e/trunk/Makefile.linux
My question was,
Currently I am started to build the code using this make file. However the
make script build only main modules not all of them
So is there any way, I can build all the modules using this scripts. Let
say example enjoy, elementary and etc are not getting build by
Makefile.linux script.
If I want build everything comes under truck how can I do it ? what are the
options to pass to build them all not just main ones ?
-Suresh
On Sat, Mar 24, 2012 at 10:31 PM, Jeff Hoogland <JeffHo...@linux.com>wrote:
> I can't really help on the details of the easy_e17 script - it has been
> some years since I last used that. Hopefully someone that knows it can lend
> you a hand :)
>
> On Sat, Mar 24, 2012 at 9:22 PM, Suresh Kumar <unique...@gmail.com
> >wrote:
>
> > Hello Jeff,
> >
> > I forgot to ask this, does this makefile.linux script will have option to
> > build all the packages which includes optional ( Try to build everything
> > and install )
> >
> >
> > -Suresh.
> >
> > On Sat, Mar 24, 2012 at 10:18 PM, Suresh Kumar <unique...@gmail.com
Jeff Hoogland
something such as the easy_e17 script to build everything.
thomasg
Hello Suresh,
you really got a few things mixed up here.
Easy_e17.sh is by no means a build system, and certainly not
Enlightenments build system.
Most of enlightenments sub-projects (libraries, applications, modules,
...) use autofoo (automake, autoconf, and consorts) as a build system.
The build system is per application, not for the whole SVN.
That's not the buildsystems job and so it will never be done.
Easy_e17 however is used to build and install all supported
applications in E's SVN by using their build systems. Therefore it is
more similar to a simple package manager than a build system. It
generally works well and is actively being developed, so if you report
bugs they likely will get fixed. As E SVN does change often and
quickly, it is necessary to change Easy_e17 now and then, too.
Endusers should not use SVN if they expect things to "just work" and
so they should not use Easy_e17 unless they're willing to at least
report bugs. It is the distributions job to provide the packages for
those users. There is no excuse for any distribution not to include
the Enlightenment Libraries (EFL), as they experience regular
releases. E17 itself has not yet been released, but released snapshots
could be easily used for packaging by distributors.
The Makefile.linux in E's root directory only builds a small set of
packages and thus is not comparable to Easy_e17.
~thomasg
Carsten Haitzler
i do think you are a bit confused here. easy-e17 is a script that walks many
sub-projects (libs an apps) and builds those. each and every project has a
build "system" (autoconf/automake and friends) already. easy-e17 takes over the
job a developer (or packager) would normally do for you and does a very fine
job of it considering it has to deal with a LIVE codebase thats is fluid and
keeps changing. as such cmake IS a replacement for autoconf/automake etc. so
that's a "red herring" - it doesn't help in your case, it just changes what we
have. (the debate on cmake vs autofoo is a topic all of its own and i won't go
into that here).
if you want easy - use packages made for your distro. there are many options.
if your distro doesn't have packages, then it's not popular enough to be
supported, so you either support yourself, or change distro.
your 2 problems are inherent problems of dealing WITH a live source tree. we
developers deal with them every day. the m4 problem is due to there being
auto-generated files or directories in your local tree that NOW have become
managed by svn. EVERY SCMS will complain in this situation as it has a
conflict. your solution would be to WIPE your entire svn checkout tree every
time before running easy_e17.sh. (i can come up with other imaginative
solutions, but they all will either consume extra disk space). by using
easy_e17.sh you are taking on the role of a packager or developer, but its SO
easy, you barely notice, and when something does go wrong, you will need to
deal with it just like packagers/developers. providing feedback on error cases
easy_e17 doesn't handle well is useful and morlenxus can improve it - or send
patches to the script to improve it.
the language module moving issue is again normal - we move things around. as
such a big issue is that easy_e17 supports building LOTS of things in SVN that
are not actively maintained or released. things crawling with bugs that will
never have them fixed. look at our download page and see what set of projects
actually make it to release. those also will make it to packages too - or
should.
one thing you want to be wary of *IS* building everything. building just core
things we release is safe, unless you want to start dealing with breakages
often.
supporting releases in a linux world inherently is nasty and hard, due to the
1000+ linux distros and packaging. thus MOST projects just release source
tarballs and leave it up to each distros packagers to packages stuff. this is
just how it works as doing it all ourselves is nigh impossible. even so - we DO
have packages built by team and community members for some distros.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
Daniel Juyung Seo
Suresh Kumar just wants us(efl-team) to have one good script to build
up-to-date svn codes.
easy_17.sh has been doing good job so far. But efl svn code changes a
lot and for some reason easy_17.sh was not updated.
When I see easy_e17.sh link, it has not been updated for a couple of years.
http://omicron.homeip.net/projects/easy_e17/easy_e17.sh
Maybe Morlenxus was busy or he lost the interest anymore.
I also hope we have one good script for building trunk. But
maintaining will be a main issue. There are many un-maintained code in
trunk and how many code does this script have to cover? And even some
projects have build error issue.
So some e-developers have their own scripts. Have a look at trunk/devs.
I also maintain my own script in trunk/devs/seoz/build.sh
This is very primitive and I build all codes I'm interested in.
Anyhow, I agree with Suresh Kumar's opinion that we need to have a
official build script for people who want to use up-to-date svn
code(including e-developer themselves). But as I mentioned, there are
some practical issue.
Thanks.
Daniel Juyung Seo (SeoZ)
On Sun, Mar 25, 2012 at 12:23 PM, Suresh Kumar <unique...@gmail.com> wrote:
> Hello Thomas,
>
> Thanks for your prompt reply and clarifying it in details...
>
> I understand that easy_17 is not part of enlightenment development and it
> is a third part script which download and install.
>
> Lets keep easy_17 topic aside for the moment and I would like to know if I
> am interested in latest e17 functionalities to use and report bugs as an
> end user then I can able to build e17 code using Makefile.linux which
> builds the following packages as below
>
> e e_dbus eet efreet embryo python-ecore python-edje ecore
> edje eeze eina evas python-e_dbus python-evas
>
> If I want to build remaining supported applications such as enjoy,
> elementary and so on. Do I need to go to individual folders and compile and
> install ? If so, is there other way to do it in one short ?
>
> Sorry for the inconvenience, I am trying to get all the packages to install
> and keep them up to date.
>
> Thanks in advance.
Carsten Haitzler
> Hello Thomas,
>
> Thanks for your prompt reply and clarifying it in details...
>
> I understand that easy_17 is not part of enlightenment development and it
> is a third part script which download and install.
>
> Lets keep easy_17 topic aside for the moment and I would like to know if I
> am interested in latest e17 functionalities to use and report bugs as an
> end user then I can able to build e17 code using Makefile.linux which
> builds the following packages as below
>
> e e_dbus eet efreet embryo python-ecore python-edje ecore
> edje eeze eina evas python-e_dbus python-evas
>
> If I want to build remaining supported applications such as enjoy,
> elementary and so on. Do I need to go to individual folders and compile and
> install ? If so, is there other way to do it in one short ?
>
> Sorry for the inconvenience, I am trying to get all the packages to install
> and keep them up to date.
>
> Thanks in advance.
use easy-e17.sh as you have been. that makefile is for buildbot. not for you.
sometimes things get removed from svn so u have to stop building it. sometimes
u get file conflicts - that's life.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
Carsten Haitzler
said:
> Actually this is not a question about build systems.
> Suresh Kumar just wants us(efl-team) to have one good script to build
> up-to-date svn codes.
easy-e17.sh
> easy_17.sh has been doing good job so far. But efl svn code changes a
> lot and for some reason easy_17.sh was not updated.
> When I see easy_e17.sh link, it has not been updated for a couple of years.
> http://omicron.homeip.net/projects/easy_e17/easy_e17.sh
> Maybe Morlenxus was busy or he lost the interest anymore.
it hasn't been updated because it hasn't needed changes. i used to have a
get_e.sh - no one wanted to use it because it didn't build all these extra
modules and stuff that's not core/maintained. people want everything in svn even
if its junk. easy-e17 tried to build much more than it should in this case. we
just don't have the manpower to maintain all of that extra "junk" in svn, but
somehow people insist on having it. my advice is - don't use it, the
alternative is we start removing anything non-core and maintained from svn, and
that will piss many people off. there is no winning.
> I also hope we have one good script for building trunk. But
> maintaining will be a main issue. There are many un-maintained code in
> trunk and how many code does this script have to cover? And even some
> projects have build error issue.
easy-e17.sh - it has been doing the job well for a very long time. it hasnt
NEEDED changes for years. :)
if you're a developer you'll end up customising your own build. if you are not
there is easy-e17.sh :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
P Purkayastha
On Sunday, March 25, 2012 1:51:33 PM UTC+8, Daniel Juyung Seo wrote:
>
> Actually this is not a question about build systems.
> Suresh Kumar just wants us(efl-team) to have one good script to build
> up-to-date svn codes.
>
> easy_17.sh has been doing good job so far. But efl svn code changes a
> lot and for some reason easy_17.sh was not updated.
> When I see easy_e17.sh link, it has not been updated for a couple of years.
> http://omicron.homeip.net/projects/easy_e17/easy_e17.sh<http://omicron.homeip.net/projects/easy_e17/easy_e17.sh>
> Maybe Morlenxus was busy or he lost the interest anymore.
>
That is the released version. There are at least three other versions which
are at various stages of "up-to-dateness":
1. morlenxus's dev version:
http://omicron.homeip.net/files/easy_e17_preview.sh
2. Jeremy's git ready version:
http://cgit.asynk.ch/cgi-bin/cgit/bin/tree/easy_e17.sh
3. My fork of morlenxus's dev version:
https://github.com/ppurka/easy_e17/blob/master/easy_e17_preview.sh
P Purkayastha
On Sunday, March 25, 2012 2:51:40 PM UTC+8, P Purkayastha wrote:
>
>
>
> On Sunday, March 25, 2012 1:51:33 PM UTC+8, Daniel Juyung Seo wrote:
>>
>> Actually this is not a question about build systems.
>> Suresh Kumar just wants us(efl-team) to have one good script to build
>> up-to-date svn codes.
>>
>> easy_17.sh has been doing good job so far. But efl svn code changes a
>> lot and for some reason easy_17.sh was not updated.
>> When I see easy_e17.sh link, it has not been updated for a couple of
>> years.
>> http://omicron.homeip.net/projects/easy_e17/easy_e17.sh<http://omicron.homeip.net/projects/easy_e17/easy_e17.sh>
>> Maybe Morlenxus was busy or he lost the interest anymore.
>>
> That is the released version. There are at least three other versions
> which are at various stages of "up-to-dateness":
>
> 1. morlenxus's dev version:
> http://omicron.homeip.net/files/easy_e17_preview.sh<http://omicron.homeip.net/files/easy_e17_preview.sh>
> 2. Jeremy's git ready version:
> http://cgit.asynk.ch/cgi-bin/cgit/bin/tree/easy_e17.sh<http://cgit.asynk.ch/cgi-bin/cgit/bin/tree/easy_e17.sh>
> 3. My fork of morlenxus's dev version:
> https://github.com/ppurka/easy_e17/blob/master/easy_e17_preview.sh<https://github.com/ppurka/easy_e17/blob/master/easy_e17_preview.sh>
>
To add to the above, I believe Jeremy's version is the most up to date. And
the package list is also more up to date.
I made the fork because I wanted a different compilation system. In
particular, it addresses the problem that raster mentions about the
autogenerated "m4 problem" that svn has to deal with. I haven't been very
diligent about keeping a very up to date package list because 1) I don't
use only the main e packages + some from emodules extra + elm. 2) I don't
have the time to update and check whether every package from svn compiles.
P Purkayastha
On Sunday, March 25, 2012 3:00:38 PM UTC+8, P Purkayastha wrote:
On Sunday, March 25, 2012 2:51:40 PM UTC+8, P Purkayastha wrote:
On Sunday, March 25, 2012 1:51:33 PM UTC+8, Daniel Juyung Seo wrote:
Actually this is not a question about build systems.
Suresh Kumar just wants us(efl-team) to have one good script to build
up-to-date svn codes.
easy_17.sh has been doing good job so far. But efl svn code changes a
lot and for some reason easy_17.sh was not updated.
When I see easy_e17.sh link, it has not been updated for a couple of years.
http://omicron.homeip.net/projects/easy_e17/easy_e17.sh
Maybe Morlenxus was busy or he lost the interest anymore.
That is the released version. There are at least three other versions which are at various stages of "up-to-dateness":1. morlenxus's dev version: http://omicron.homeip.net/files/easy_e17_preview.sh
2. Jeremy's git ready version: http://cgit.asynk.ch/cgi-bin/cgit/bin/tree/easy_e17.sh
3. My fork of morlenxus's dev version: https://github.com/ppurka/easy_e17/blob/master/easy_e17_preview.sh
To add to the above, I believe Jeremy's version is the most up to date. And the package list is also more up to date.I made the fork because I wanted a different compilation system. In particular, it addresses the problem that raster mentions about the autogenerated "m4 problem" that svn has to deal with. I haven't been very diligent about keeping a very up to date package list because 1) I don't use only the main e packages + some from emodules extra + elm.