[Evolution-hackers] newcomers: How should I compile Evolution?
Howdy!
I can bet that (almost) every contributor has a different way to setup the
environment, compile and use the fresh compiled Evolution and I'm here to
describe the way I do my setup (based on Matthew's setup) :-)
Firstly, jhbuild or not jhbuild?
--
I like to use jhbuild for a few projects that I use and contribute. But
that's not the case for Evolution. As Evolution has a small set of
dependencies and usually none of them are bleeding edge, I'd say do *not*
go for jhbuild in this case.
So, what are you using, Fabiano?
-
I'm using these 2 scripts: common and unstable (
http://rachacuca.org/~fidencio/evolution/newcomers/).
Both of them are in my $HOME/.local/bin and this folder is part of my $PATH.
Then when I open a terminal I just do "source unstable" and I'm all set to
build from the master branch :-).
When configuring evolution-data-server or evolution I use:
./configure --prefix=$PREFIX, which the "unstable" script defines to be
$HOME/local/unstable -- so that's where evolution-data-server/evolution get
installed.
*If* I need to build a base library like GTK+, then I use:
./configure --prefix=$COMMON, which the "common" script defines to be
$HOME/local/common and that way I keep base libraries separated from
evolution-data-server/evolution.
And before running Evolution, what I do is start manually the
evolution-source-registry and the factories processes
(evolution-{addressbook,calendar}-factory) located in
$HOME/local/unstable/libexec/
I do believe this is the simplest way for compiling, using and debugging
Evolution Data Server/Evolution.
Best Regards,
--
Fabiano Fidêncio
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] newcomers: How should I compile Evolution?
On Thu, 2014-03-06 at 09:58 +0100, Fabiano Fidêncio wrote: > I can bet that (almost) every contributor has a different way to setup > the environment, compile and use the fresh compiled Evolution and I'm > here to describe the way I do my setup (based on Matthew's setup) :-) Nice instructions! I should transcribe this to a wiki page. Let me amend this with a couple more tricks... I also have three scripts (or just aliases would work too) named: autogen-eds autogen-evo autogen-ews Each of these is basically just... ./autogen.sh --prefix=$PREFIX (yadda, yadda, yadda) This is where I keep the configure options I routinely use for building evolution-data-server, evolution, and evolution-ews, respectively. It's mainly just options like --enable-this or --disable-that, etc. That way I don't have to remember them all or keep them typing them all. Also, a newcomer may not need this but just for completeness, I also have a script named 'stable', which is almost the same as 'unstable', but uses a different PREFIX ($HOME/local/stable). It too references 'common', which is why 'common' is a separate script. I use 'stable' for building our latest "stable" branch, currently gnome-3-10. It uses a different install prefix so I don't mix files from the two branches. That would be bad. Also, speaking of branches, generic git trick: For me the 'git-new-workdir' script that comes with git is a life saver! It allows you have multiple working directories for the same repo without cloning the whole repo, each checked out to a different branch. That was my biggest complaint with git when I first started using it -- that to switch branches I first had to pack up whatever I was doing in the current working directory, switch branches, and wipe the working directory clean so I don't pick up build artifacts from the other branch. But that increases the build time and slows me down. The 'git-new-workdir' script solves this, but it's not installed in /usr/bin for some reason. You have to dig it out of: /usr/share/doc/git/contrib/workdir or some similar place on your distro. Just copy the script to your $HOME/.local/bin, and do "git-new-workdir --help" to see how it works. That's my bag of tricks. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Proposal: Evolution 3.13 Release Schedule
On Mon, 2014-03-03 at 15:51 -0500, Matthew Barnes wrote: > Been thinking about our release schedule after 3.12.0, when we break > with GNOME and embark on our own annual development/support cycle. > > I'd like to release updates at a more predictable cadence than GNOME. > With the GNOME 3.12.0 and 3.12.1 release dates in mind, I propose the > following: > > - Release stable updates on the 2nd Monday of each month. > - Release development updates on the 4th Monday of each month. Another thing I've been thinking about is what to call our stable branch names, starting with 3.12. The usual gnome-3-x branch name is going to be confusing, especially later this year when our version number starts to diverge from GNOME's version number. I suggest just naming the branches after the module name, similar to how GLib and GTK+ do it. e.g. evolution-3-12 evolution-data-server-3-12 evolution-ews-3-12 evolution-mapi-3-12 That sound okay? I don't have a strong preference for the name, other than not using 'gnome' anymore. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Proposal: Evolution 3.13 Release Schedule
On Thu, 2014-03-06 at 09:27 -0500, Matthew Barnes wrote: > I suggest just naming the branches after the module name, similar to how > GLib and GTK+ do it. e.g. > >evolution-3-12 >evolution-data-server-3-12 >evolution-ews-3-12 >evolution-mapi-3-12 > > That sound okay? I don't have a strong preference for the name, other > than not using 'gnome' anymore. Hi, sure, works for me. After all, it'll be closer to tag names too. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] When talking about branches...
Hi, when talking about branches, what about deleting all those obsolete for years? I mean the development branches, not those release related. I believe they are useless, definitely those not touched for years (even for months, like mine where I initiated the EClient stuff couple years ago). Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] When talking about branches...
On Thu, 2014-03-06 at 16:09 +0100, Milan Crha wrote: > when talking about branches, what about deleting all those obsolete for > years? I mean the development branches, not those release related. > I believe they are useless, definitely those not touched for years (even > for months, like mine where I initiated the EClient stuff couple years > ago). Sounds okay to me. Looks like a there's a lot of cruft to sort through. I think the wip/webkit-composer branch might still be alive (ask Tomas). I don't know of any other live "wip" branches at the moment. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] When talking about branches...
On Thu, 2014-03-06 at 10:55 -0500, Matthew Barnes wrote: > I think the wip/webkit-composer branch might still be alive (ask Tomas). Right, that's the only being active currently from my point of view too (and according to commit log). Should I figure out the right git command and just get rid of those in eds/evo/ews/ema? Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] When talking about branches...
On Thu, 2014-03-06 at 17:06 +0100, Milan Crha wrote: > Right, that's the only being active currently from my point of view too > (and according to commit log). Should I figure out the right git command > and just get rid of those in eds/evo/ews/ema? Yeah, have at it. I think the commands you need are: git branch -r -- list all the remote branches git push origin : -- deletes a remote branch (I don't really understand the colon, but that's how it works.) Obviously be careful if you try to automate this or use grep or whatever. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] When talking about branches...
On Thu, 2014-03-06 at 11:40 -0500, Paul Smith wrote: > If you have a new-ish git you can use the --delete flag instead of the > colon (exactly the same result, but more readable): > > git push --delete origin Thanks for the tip, that's much easier to remember. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] When talking about branches...
On Čt, 2014-03-06 at 17:06 +0100, Milan Crha wrote: > On Thu, 2014-03-06 at 10:55 -0500, Matthew Barnes wrote: > > I think the wip/webkit-composer branch might still be alive (ask Tomas). > > Right, that's the only being active currently from my point of view too > (and according to commit log). I'm perfectly fine with removing all the unused branches, but please don't remove wip/webkit-composer and wip-webkit2 branches. Tom ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
