Hi,

On Thu, May 29, 2014 at 2:42 PM, lloyd konneker wrote:

Jehan said: There are already absolutely*NO* barrier to contribute to GIMP.

The GIMP project does not create barriers, but there is a learning-curve barrier, and a social barrier.

More discussion of psychology of nerds is in the book "Hackers and Painters". Paraphrasing: nerds don't want to be popular. Its hard work to be popular. Nerds and painters are both makers.

OpenHatch goal seems: to make developing FOSS popular among young people who want to make.

Well yes, I get that. But these people who "want to make", in the end, they still have to deal with us, not OpenHatch. What's the difference between going directly to us rather than going through a third party? Anyway maybe there is a point I miss. Future will tell us. Maybe that will be good for GIMP, who knows?

Jehan

Jehan Pags writes:

Well yes, I get that. But these people who "want to make", in the end, they still have to deal with us, not OpenHatch. What's the difference between going directly to us rather than going through a third party? Anyway maybe there is a point I miss. Future will tell us. Maybe that will be good for GIMP, who knows?

One difference: OpenHatch is explicitly oriented toward teaching and mentoring. If someone comes to OpenHatch and gets matched with someone who has signed up to be a GIMP mentor, the new person doesn't have to worry that they're pestering someone or dragging them away from projects they'd rather be doing.

Another difference: in the discussion on #openhatch the other day, someone asked if they might use GIMP as one of the programs in workshops they give, where they help teach people how to contribute to open source, then have hack sessions where groups of students get together and work on fixing bugs in the chosen projects. So they can both support each other, and get help from an experienced tutor.

I don't have any firsthand experience with OpenHatch workshops, but they sure sound like they'd be helpful both to would-be contributors and to the project.

...Akkana

There aren't any formal barriers to contributing to GIMP. There are definitely some formidable (ha!) barriers in the practical sense. Until we provide a clear step-by-step guide (on say Debian) to getting GIMP compiled from git, only the most highly-motivated and already-knowledgeable people will be *able* to contribute.

Let's not reduce our pool of contributors that way!

Ed

-----Original Message----- From: Jehan Pags
Sent: Thursday, May 29, 2014 6:01 PM To: lloyd konneker
Cc: gimp-developer
Subject: Re: [Gimp-developer] Getting contributors via OpenHatch

Hi,

On Thu, May 29, 2014 at 2:42 PM, lloyd konneker wrote:

Jehan said: There are already absolutely*NO* barrier to contribute to GIMP.

The GIMP project does not create barriers, but there is a learning-curve barrier, and a social barrier.

More discussion of psychology of nerds is in the book "Hackers and Painters". Paraphrasing: nerds don't want to be popular. Its hard work to be popular. Nerds and painters are both makers.

OpenHatch goal seems: to make developing FOSS popular among young people who
want to make.

Well yes, I get that. But these people who "want to make", in the end, they still have to deal with us, not OpenHatch. What's the difference between going directly to us rather than going through a third party? Anyway maybe there is a point I miss. Future will tell us. Maybe that will be good for GIMP, who knows?

Jehan

On 29/05/14 22:27, Ed . wrote:

There aren't any formal barriers to contributing to GIMP. There are definitely some formidable (ha!) barriers in the practical sense. Until we provide a clear step-by-step guide (on say Debian) to getting GIMP compiled from git, only the most highly-motivated and already-knowledgeable people will be *able* to contribute.

http://wiki.gimp.org/index.php/Hacking:Building

No?

Are you saying you think that's well-publicised?

Are you saying you think keen people who can program will generally be able to follow this, because it's a simple cook-book recipe to build from git?

-----Original Message----- From: Ofnuts
Sent: Saturday, May 31, 2014 9:40 PM To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Getting contributors via OpenHatch

On 29/05/14 22:27, Ed . wrote:

There aren't any formal barriers to contributing to GIMP. There are definitely some formidable (ha!) barriers in the practical sense. Until we provide a clear step-by-step guide (on say Debian) to getting GIMP compiled from git, only the most highly-motivated and already-knowledgeable people will be *able* to contribute.

http://wiki.gimp.org/index.php/Hacking:Building

No?

Here's some probably too long/too detailed instructions for building GIMP from git:

http://ninedegreesbelow.com/photography/build-gimp-in-prefix.html

If the article might be useful with modifications, I can release the text under whatever license is appropriate.

Calligra/Krita has very detailed build instructions that might make a good general guide for writing a how-to for building BABL/GEGL/GIMP:

http://community.kde.org/Calligra/Building

Elle

If you include in it the page from LightningIsMyName that it links to, definitely...

Call me cynical, but someone that needs really more detailed instructions will likely not have the programming background to be a useful Gimp developer. Of course I expect potential Gimp contributors to be somewhat "already-knowledgeable", at least in the basics of Linux application development. Lines have to be drawn somewhere...

On 01/06/14 20:39, Ed . wrote:

Are you saying you think that's well-publicised?

Are you saying you think keen people who can program will generally be able to follow this, because it's a simple cook-book recipe to build from git?

-----Original Message----- From: Ofnuts Sent: Saturday, May 31, 2014 9:40 PM To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Getting contributors via OpenHatch

On 29/05/14 22:27, Ed . wrote:

There aren't any formal barriers to contributing to GIMP. There are definitely some formidable (ha!) barriers in the practical sense. Until we provide a clear step-by-step guide (on say Debian) to getting GIMP compiled from git, only the most highly-motivated and already-knowledgeable people will be *able* to contribute.

http://wiki.gimp.org/index.php/Hacking:Building

El dom, 01-06-2014 a las 21:49 +0200, Ofnuts escribió:

If you include in it the page from LightningIsMyName that it links to, definitely...

Call me cynical, but someone that needs really more detailed instructions will likely not have the programming background to be a useful Gimp developer. Of course I expect potential Gimp contributors to be somewhat "already-knowledgeable", at least in the basics of Linux application development. Lines have to be drawn somewhere...

+1
I'm not a coder, just a user and I could manage to build GIMP from git without too much hassle.

Some things may be not exactly obvious, but I want to believe that somebody who intends to contribute in a software project will be at least equiped to compile the thing from sources.

If that's supposed to be an entry barrier, I think it's a good one.

Gez

On 02/06/14 00:41, Gez wrote:

El dom, 01-06-2014 a las 21:49 +0200, Ofnuts escribió:

If you include in it the page from LightningIsMyName that it links to, definitely...

Call me cynical, but someone that needs really more detailed instructions will likely not have the programming background to be a useful Gimp developer. Of course I expect potential Gimp contributors to be somewhat "already-knowledgeable", at least in the basics of Linux application development. Lines have to be drawn somewhere...

+1
I'm not a coder, just a user and I could manage to build GIMP from git without too much hassle.

Some things may be not exactly obvious, but I want to believe that somebody who intends to contribute in a software project will be at least equiped to compile the thing from sources.

If that's supposed to be an entry barrier, I think it's a good one.

Gez

I don't think it's an explicitly laid down barrier. But after all the maintenance manual of my bike assumes that you know how to operate a torque wrench and what SAE 20W50 means. If you don't you better keep your hands off the engine :)

Presumably you guys also think GIMP's documentation (contained in comments in the code) is absolutely perfect, and that the only meaningful contributions to GIMP are substantive code changes?

If so, then the only people who could add value to GIMP are people who can clear your barrier of super technical competence.

If not...

-----Original Message----- From: Ofnuts
Sent: Monday, June 02, 2014 12:52 AM To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Getting contributors via OpenHatch

On 02/06/14 00:41, Gez wrote:

El dom, 01-06-2014 a las 21:49 +0200, Ofnuts escribió:

If you include in it the page from LightningIsMyName that it links to, definitely...

Call me cynical, but someone that needs really more detailed instructions will likely not have the programming background to be a useful Gimp developer. Of course I expect potential Gimp contributors to be somewhat "already-knowledgeable", at least in the basics of Linux application development. Lines have to be drawn somewhere...

+1
I'm not a coder, just a user and I could manage to build GIMP from git without too much hassle.

Some things may be not exactly obvious, but I want to believe that somebody who intends to contribute in a software project will be at least equiped to compile the thing from sources.

If that's supposed to be an entry barrier, I think it's a good one.

Gez

I don't think it's an explicitly laid down barrier. But after all the maintenance manual of my bike assumes that you know how to operate a torque wrench and what SAE 20W50 means. If you don't you better keep your hands off the engine :)

On 29.5.2014 at 10:27 PM Ed . wrote:

There aren't any formal barriers to contributing to GIMP. There are definitely some formidable (ha!) barriers in the practical sense. Until we provide a clear step-by-step guide (on say Debian) to getting GIMP compiled from git, only the most highly-motivated and already-knowledgeable people will be *able* to contribute.

Let's not reduce our pool of contributors that way!

Ed

+1

I also found this as a IMHO quite good beginner documentation: https://wiki.videolan.org/Getting_Started_At_Coding/ and https://wiki.videolan.org/Compile_VLC/

Kind regards,

Sven

On 1.6.2014 at 9:49 PM Ofnuts wrote:

If you include in it the page from LightningIsMyName that it links to, definitely...

Call me cynical, but someone that needs really more detailed instructions will likely not have the programming background to be a useful Gimp developer. Of course I expect potential Gimp contributors to be somewhat "already-knowledgeable", at least in the basics of Linux application development.

I would not reduce it to only Linux development: We have a big lack of Windows developers or they have not enough time, so Windows developers are very welcome, too.

And: contributions are not only coding. For example user support, bug reporting and triaging, documentation, translation, contributing high-quality assets, test and constructive user feedback/domain guidance, website maintenance are also contributions and they don't need knowledge of Linux application development.

Kind regards,

Sven

On 02/06/14 03:29, Ed . wrote:

Presumably you guys also think GIMP's documentation (contained in comments in the code) is absolutely perfect, and that the only meaningful contributions to GIMP are substantive code changes?

You are changing subject here... We are no longer talking about building the code...

If so, then the only people who could add value to GIMP are people who can clear your barrier of super technical competence.

Seriously, if you think that building Gimp requires "superior technical competence"...

scl wrote:

And: contributions are not only coding. For example user support, bug reporting and triaging, documentation, translation, contributing high-quality assets, test and constructive user feedback/domain guidance, website maintenance are also contributions and they don't need knowledge of Linux application development.

damn right, there are so many more ways to contribute.

a structure for making sense of this:

- define as a project which types of contributors we need to attract - be realistic, for each of these groups, about - which skills they need to bring (re building and code) - on what installation (latest release, or daily build?) they need to be - do they really need to build something as part of their contribution process? - evaluate what is there right now; note what is crummy and what is missing.

then you know what needs to be done.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

On 06/01/2014 03:49 PM, Ofnuts wrote:

Call me cynical, but someone that needs really more detailed instructions will likely not have the programming background to be a useful Gimp developer. Of course I expect potential Gimp contributors to be somewhat "already-knowledgeable", at least in the basics of Linux application development. Lines have to be drawn somewhere...

I've shown several people how to build GIMP from git. One person was a c coder who wanted to write and submit a patch. Which he did. Another person is currently working on a patch.

For these two people the entry barrier of figuring out how to build GIMP from git would have been a waste of time.

Coding skills are separable from the software-specific knowledge of how to compile from source. I've compiled a lot of software from source, and each time there's a unique set of challenges in terms of getting all the dependencies in line.

The Calligra build instructions (http://community.kde.org/Calligra/Building) make it possible for potential new code contributors to all work with the same setup. This way:

*The Calligra developers don't have to worry about whether the potential new contributor compiled the software in some odd way that's causing problems.

*The potential new contributor doesn't have to reinvent the wheel as they figure out how to get all the dependencies installed.

Wouldn't GIMP benefit from similarly precise, step-by-step build instructons?

Regards,

Elle Stone

Von: "Elle Stone"

On 06/01/2014 03:49 PM, Ofnuts wrote:

Call me cynical, but someone that needs really more detailed instructions will likely not have the programming background to be a useful Gimp developer. Of course I expect potential Gimp contributors to be somewhat "already-knowledgeable", at least in the basics of Linux application development. Lines have to be drawn somewhere...

I've shown several people how to build GIMP from git. One person was a c coder who wanted to write and submit a patch. Which he did. Another person is currently working on a patch.

Was there a special part they needed help with?

For these two people the entry barrier of figuring out how to build GIMP from git would have been a waste of time.

I've read the build guide you posted yesterday, and was a bit confused by it. Mostly because it addresses issues I've never encountered as such, so I'm not sure how much of it is based on actually experienced blocking points (for example, the "running gimp from a prefix by creating a launcher script" part is puzzling me - either I'm always running my GIMP 2.9.x the wrong way, or it simply works for me...).

Regarding said build instructions:

- the config.site approach as described in e.g. Martin Nordholt's blog works fine for me I've never ever had to remember to set environment variables again

Getting the dependencies is:

- easy on reasonably recent Linux distros (apt-get build-dep, zypper -d, ...). - apparently not much harder for OSX if you use Homebrew and Macports, there are reports of successful builds - hardest on the Windows platform (although the current mingw installers make this easier) - but even the official installers are compiled *for* Windows *on* Linux

We have some build instrcutions for all of these, the problem is review - which probably doesn't happen because the people who could review them fully don't need them anymore? :)

Where OpenHatch will provide the most benefit:

- enable user to discover that there is something beyond the icons of the desktop environment, for example a command line interface - enable users to get to the point where building any software or documentation, including babl, gegl, gimp, the gimp user manual, plug-ins, ..., becomes a no-brainer - i.e. understanding messages like "needs libfoo..." and make it become "ahhh, I'll just get it from my the package management"

Regards,
Michael

Did you know that if you change the PDB docs, you need to run the build process to change the two resulting C files in order to generate a correct patch (for 3 files)?

-----Original Message----- From: Ofnuts
Sent: Monday, June 02, 2014 9:52 AM
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Getting contributors via OpenHatch

On 02/06/14 03:29, Ed . wrote:

Presumably you guys also think GIMP's documentation (contained in comments in the code) is absolutely perfect, and that the only meaningful contributions to GIMP are substantive code changes?

You are changing subject here... We are no longer talking about building the code...

If so, then the only people who could add value to GIMP are people who can clear your barrier of super technical competence.

Seriously, if you think that building Gimp requires "superior technical competence"...

On 06/02/2014 11:32 AM, Michael Schumacher wrote:

Von: "Elle Stone"

I've shown several people how to build GIMP from git.

Was there a special part they needed help with?

No. They just wanted the quickest, easiest way to compile GIMP from git. I sent they my "cheat sheet" of commands and referred them to the article if any of the commands on the cheat sheet didn't make sense.

I've read the build guide you posted yesterday, and was a bit confused by it.

Two years ago, when I wrote that article, it took me several days of trawling the internet before I succeeded in putting together a set of commands for building GIMP from git. I didn't consider that time well-spent, and I was hardly a newbie at Linux, the command line, or building software from source.

I wrote the article mostly to remind myself what the steps are. Also a lot of people on the GIMP user list were complaining about 2.8, so I thought it would be neat to figure out how to install 2.6, 2.8, and 2.9 all at once.

If I were writing the article today, I'd write it differently. I wasn't putting it forward as a model of clarity but rather in case there were parts someone wanted to use.

I think the Calligra build instructions are in fact a model of clarity and would make an excellent template for writing up how to build GIMP from git.

Regarding said build instructions:

- the config.site approach as described in e.g. Martin Nordholt's blog works fine for me I've never ever had to remember to set environment variables again

Two years ago I did find the Nordholt article but I couldn't figure out what he meant by "config.site". I still can't. Looking at http://www.gimp.org/source/howtos/gimp-git-build.html, perhaps the line:

export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal $ACLOCAL_FLAGS"

has something to do with "config.site"?

So I followed Shallowsky's and Lightning's instructions instead.

Getting the dependencies is:

- easy on reasonably recent Linux distros (apt-get build-dep, zypper -d, ...).

The Calligra build instructions have a nice set of "how tos" for the dependencies for the most popular Linux distros. This is a nice touch because it does vary from distro to distro. Not everyone already knows about these commands.

Where OpenHatch will provide the most benefit:

- enable user to discover that there is something beyond the icons of the desktop environment, for example a command line interface - enable users to get to the point where building any software or documentation, including babl, gegl, gimp, the gimp user manual, plug-ins, ..., becomes a no-brainer - i.e. understanding messages like "needs libfoo..." and make it become "ahhh, I'll just get it from my the package management"

It's not that compiling from source is such a big deal. But why not make it as easy as possible for people building GIMP for the first time? Maybe put in a few sentences here and there explaining the obvious to people for whom it might not be so obvious?

Elle

On 02/06/14 05:13, scl wrote:

On 1.6.2014 at 9:49 PM Ofnuts wrote:

If you include in it the page from LightningIsMyName that it links to, definitely...

Call me cynical, but someone that needs really more detailed instructions will likely not have the programming background to be a useful Gimp developer. Of course I expect potential Gimp contributors to be somewhat "already-knowledgeable", at least in the basics of Linux application development.

I would not reduce it to only Linux development: We have a big lack of Windows developers or they have not enough time, so Windows developers are very welcome, too.

And: contributions are not only coding. For example user support, bug reporting and triaging, documentation, translation, contributing high-quality assets, test and constructive user feedback/domain guidance, website maintenance are also contributions and they don't need knowledge of Linux application development.

I totally agree with that, but I'll add that these people don't really need to build their own Gimp either.

Hi,

On Mon, Jun 2, 2014 at 6:18 PM, Elle Stone wrote:

On 06/02/2014 11:32 AM, Michael Schumacher wrote:

Von: "Elle Stone"

I've shown several people how to build GIMP from git.

Was there a special part they needed help with?

No. They just wanted the quickest, easiest way to compile GIMP from git. I sent they my "cheat sheet" of commands and referred them to the article if any of the commands on the cheat sheet didn't make sense.

Like some others here, I don't really get it. I never had any problem with GIMP compilation. GIMP uses the very common tryptic of all GNU projects (and most Free Software): ./configure && make && make install It has some dependencies, especially when compiling the git version, but they all follow the same 3-command method. I just don't get what is difficult with this.
Note that I don't say this is flawless and there can't be any issue during building, but when that happens, that's a bug in the compilation process (and by itself, fixing this can be a very valid patch). In any cases *usually* this works perfectly. This is the most common compilation process ever. How can this be considered a barrier for contribution?
I don't even understand how anyone may want more than what is already in the INSTALL file (which is already quite complete)...

All projects with huge contribution rate have the *very exact* same compilation process (or a very similar one).

Jehan

I've read the build guide you posted yesterday, and was a bit confused by it.

Two years ago, when I wrote that article, it took me several days of trawling the internet before I succeeded in putting together a set of commands for building GIMP from git. I didn't consider that time well-spent, and I was hardly a newbie at Linux, the command line, or building software from source.

I wrote the article mostly to remind myself what the steps are. Also a lot of people on the GIMP user list were complaining about 2.8, so I thought it would be neat to figure out how to install 2.6, 2.8, and 2.9 all at once.

If I were writing the article today, I'd write it differently. I wasn't putting it forward as a model of clarity but rather in case there were parts someone wanted to use.

I think the Calligra build instructions are in fact a model of clarity and would make an excellent template for writing up how to build GIMP from git.

Regarding said build instructions:

- the config.site approach as described in e.g. Martin Nordholt's blog works fine for me
I've never ever had to remember to set environment variables again

Two years ago I did find the Nordholt article but I couldn't figure out what he meant by "config.site". I still can't. Looking at http://www.gimp.org/source/howtos/gimp-git-build.html, perhaps the line:

export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal $ACLOCAL_FLAGS"

has something to do with "config.site"?

So I followed Shallowsky's and Lightning's instructions instead.

Getting the dependencies is:

- easy on reasonably recent Linux distros (apt-get build-dep, zypper -d, ...).

The Calligra build instructions have a nice set of "how tos" for the dependencies for the most popular Linux distros. This is a nice touch because it does vary from distro to distro. Not everyone already knows about these commands.

Where OpenHatch will provide the most benefit:

- enable user to discover that there is something beyond the icons of the desktop environment, for example a command line interface - enable users to get to the point where building any software or documentation, including babl, gegl, gimp, the gimp user manual, plug-ins, ..., becomes a no-brainer
- i.e. understanding messages like "needs libfoo..." and make it become "ahhh, I'll just get it from my the package management"

It's not that compiling from source is such a big deal. But why not make it as easy as possible for people building GIMP for the first time? Maybe put in a few sentences here and there explaining the obvious to people for whom it might not be so obvious?

Elle

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

On Mon, Jun 2, 2014 at 6:40 PM, Jehan Pagès wrote:

Hi,

On Mon, Jun 2, 2014 at 6:18 PM, Elle Stone ...
Like some others here, I don't really get it. I never had any problem with GIMP compilation. GIMP uses the very common tryptic of all GNU projects (and most Free Software): ./configure && make && make install It has some dependencies, especially when compiling the git version, but they all follow the same 3-command method. I just don't get what is difficult with this.
...
Jehan

Clearly you've never compiled on Windows and/or Mac and hence you make such statements.

Hi,

On Mon, Jun 2, 2014 at 11:11 PM, Partha Bagchi wrote:

On Mon, Jun 2, 2014 at 6:40 PM, Jehan Pagès wrote:

Hi,

On Mon, Jun 2, 2014 at 6:18 PM, Elle Stone ...

Like some others here, I don't really get it. I never had any problem with GIMP compilation. GIMP uses the very common tryptic of all GNU projects (and most Free Software): ./configure && make && make install It has some dependencies, especially when compiling the git version, but they all follow the same 3-command method. I just don't get what is difficult with this.
...
Jehan

Clearly you've never compiled on Windows and/or Mac and hence you make such statements.

Well you take some serious assumption here, since I'm one of the rare GIMP devs who sometimes fixes bugs for Windows! I did once compiled on Windows, the problem was that it was slow as hell, but the compilation in itself was using the same 3 commands (once the environment was set-up, which is usually indeed very annoying on Windows but only done once). Now I rather cross-compile on Linux for Windows regularly. And it's fast and easy. Of course it means to understand the logics of cross-compiling first and that takes some time the first time as well. But computer science is not magic. Things take time. Developers need to understand things (and if a developer is not even *willing* to spare a little time to understand the overall concept of compilation, seriously I would doubt one's capacity to help our project efficiently).

Do you have *any* example of other program which does things better than us as for compilation process? As said, we have the most common compilation system (the GNU one, in particular using the autotools. I have several dozen local repositories of various projects in my hard drive, they nearly all use the same), so that sounds strange to hear it can be a blocker.

Jehan

Hi,

On Tue, Jun 3, 2014 at 11:34 PM, Ed . wrote:

Hi Jehan,

Could you share your cookbook for setting up cross-compiling to Windows?

Sorry for the very late answer. I wanted to release a new version of my cross-compilation tool before answering (because my locale copy was already so much more advanced). Sorry for having let the time slide that much. :-)

I have basically written a tool to help me cross compiling very easily. See there: https://pypi.python.org/pypi/crossroad/ This is a python 3 tool, which you can install with:

$ pip3 install crossroad

You will need the following dependencies: 7z or rpm2cpio, gcc-mingw-w64-i686, g++-mingw-w64-i686, binutils-mingw-w64-i686 (gcc-mingw-w64-x86-64, g++-mingw-w64-i686, and binutils-mingw-w64-x86-64 respectively for 64-bit Windows).

Once all is installed, below my exact cookbook for compiling GIMP master, for instance for Windows 64-bit:

$ crossroad w64

Installing various dependencies: $ crossroad install win_iconv-devel libtiff-devel iso-codes-devel liblzma-devel zlib-devel libbz2-devel libbz2-1 libexpat-devel libexpat1 gtk2-devell ibSDL-devel liblcms2-2 liblcms2-devel

Compile babl, GEGL, cairo, all with the same procedure: Note 1: there are babl/GEGL/cairo packages in the pre-compiler packages, but the versions are not right for GIMP master. I use babl and GEGL from git master, and cairo 1.12.16. They work ok for me. Note 2: you may want to clone these repo just for Windows, rather than using the ones you use for native Linux compiling, if you plan to regularly compile for both platforms. Actually you may even want to have one for Win 32 and one for 64 bit.

$ cd babl (respectively gegl/ and cairo/) $ crossroad configure
Note: for GEGL, you must currently add --disable-docs option. Our GEGL doc generation does not handle well cross-build. See Bug 733667 . $ make -j
$ make -j install

Exiv2 (svn trunk) uses cmake: $ svn checkout svn://dev.exiv2.org/svn/trunk exiv2-trunk $ cd exiv2-trunk
$ crossroad cmake .
$ make
$ make install

Then gexiv2 (git master), same as babl/GEGL: $ cd gexiv2
$ crossroad configure && make && make install

Finally compile GIMP master the same way. Note that I disable python because it is not in the pre-built packages and I never really needed it, but that should not be very difficult to cross-compile it the same way as the rest (Python uses the configure/make/make install triplet as well).
$ cd gimp
$ crossroad configure --disable-python $ make
$ make install

To test it, I use a Windows 7 VM. I have a shared directory. I exit crossroad (ctrl-d), go to the shared dir: $ cd /my/share/virtualbox/dir/
$ crossroad -s w64

It creates a w64/ link, that I see as a directory in my Windows VM. Alternatively, I could create a compressed archive to uncompress on Win:
$ crossroad -c gimp-master.zip w64

And that's it! You have a working GIMP for Windows. I do the whole process in less than 30 min, build time included. You could even really easily automatize these in a script. Note that you can add more dependencies (either by using pre-compiled package. You can search them with `crossroad search` then install with `crossroad install`; or compiling them yourself), but I just showed a basic installation.

Jehan

Cheers,

Ed

-----Original Message----- From: Jehan Pagès Sent: Tuesday, June 03, 2014 9:41 AM To: Partha Bagchi
Cc: Gimp-developer

Subject: Re: [Gimp-developer] Getting contributors via OpenHatch

Hi,

On Mon, Jun 2, 2014 at 11:11 PM, Partha Bagchi wrote:

On Mon, Jun 2, 2014 at 6:40 PM, Jehan Pagès wrote:

Hi,

On Mon, Jun 2, 2014 at 6:18 PM, Elle Stone ...

Like some others here, I don't really get it. I never had any problem with GIMP compilation. GIMP uses the very common tryptic of all GNU projects (and most Free Software): ./configure && make && make install It has some dependencies, especially when compiling the git version, but they all follow the same 3-command method. I just don't get what is difficult with this.
...
Jehan

Clearly you've never compiled on Windows and/or Mac and hence you make such
statements.

Well you take some serious assumption here, since I'm one of the rare GIMP devs who sometimes fixes bugs for Windows! I did once compiled on Windows, the problem was that it was slow as hell, but the compilation in itself was using the same 3 commands (once the environment was set-up, which is usually indeed very annoying on Windows but only done once). Now I rather cross-compile on Linux for Windows regularly. And it's fast and easy. Of course it means to understand the logics of cross-compiling first and that takes some time the first time as well. But computer science is not magic. Things take time. Developers need to understand things (and if a developer is not even *willing* to spare a little time to understand the overall concept of compilation, seriously I would doubt one's capacity to help our project efficiently).

Do you have *any* example of other program which does things better than us as for compilation process? As said, we have the most common compilation system (the GNU one, in particular using the autotools. I have several dozen local repositories of various projects in my hard drive, they nearly all use the same), so that sounds strange to hear it can be a blocker.

Jehan
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list