On Sun, Jul 29, 2012 at 4:11 AM, Malix wrote:

I already know that this post will generate a lot of flames.

But you do it anyway?

Next step of the project is the porting of the code to Gtk 3

It started over a year ago, it's just lower priority right now.

why instead not switching away from gtk and go with Qt?

Because developers prefer GTK+? Because GTK+ was born from GIMP, so there's a bond between the two projects?

And also leave autohell and switch to make?

What is make, please? Are you referring to CMake maybe? :)

Personally I don't mind it. Would you like to provide a patch?

You can think that I'm just kidding but consider those two blog post

No, you are "merely" suggesting to scrap a lot of work on GTK3 port that's already done.

http://blogs.gnome.org/otte/2012/07/23/self-congratulating-echo-chamber/

I think you really intended to link to http://blogs.gnome.org/otte/2012/07/27/staring-into-the-abyss/ instead. There are some good points and some horrible points there. You do not explain however, what is it exactly that made you link to this blog posting.

http://blog.mardy.it/2012/05/from-g-to-q.html?m=1

Sorry, but sending people to a wall of text is not very helpful. You'll have to explain what you were meant to say with this link :)

Alexandre Prokoudine http://libregraphicsworld.org

On 07/29/12 02:11, Malix wrote:

I already know that this post will generate a lot of flames. Next step of the project is the porting of the code to Gtk 3, why instead not switching away from gtk and go with Qt? And also leave autohell and switch to make?

You can think that I'm just kidding but consider those two blog post

http://blogs.gnome.org/otte/2012/07/23/self-congratulating-echo-chamber/

http://blog.mardy.it/2012/05/from-g-to-q.html?m=1

The second link is particularly interesting. Thanks.

On Sun, 29 Jul 2012 02:11:20 +0200 Malix wrote:

I already know that this post will generate a lot of flames. Next step of the project is the porting of the code to Gtk 3, why instead not switching away from gtk and go with Qt? And also leave autohell and switch to make?

You can think that I'm just kidding but consider those two blog post

http://blogs.gnome.org/otte/2012/07/23/self-congratulating-echo-chamber/

http://blog.mardy.it/2012/05/from-g-to-q.html?m=1

Ciao Massimo,

I am not sure how deep you are in using Qt as a developer.

I like Qt very much, as much as I like the Gimp, but believe me: Porting Gimp to Qt would be a very big and time-consuming task - and to do it RIGHT it would require re-design of big areas of code ...

Are ressources for that available? Who could lead and participate in such a big project?

IMHO it makes more sense to go on making Gimp better by fixing bugs, but of course that is just my personal opinion.

Cheers Karl-Heinz

Hi all,

On Sun, 29 Jul 2012 04:44:21 +0400 Alexandre Prokoudine wrote:

On Sun, Jul 29, 2012 at 4:11 AM, Malix wrote:

I already know that this post will generate a lot of flames.

But you do it anyway?

Next step of the project is the porting of the code to Gtk 3

It started over a year ago, it's just lower priority right now.

why instead not switching away from gtk and go with Qt?

Because developers prefer GTK+? Because GTK+ was born from GIMP, so there's a bond between the two projects?

And also leave autohell and switch to make?

What is make, please? Are you referring to CMake maybe? :)

They meant CMake, yes (as they noted in the followup E-mail).

Personally I don't mind it. Would you like to provide a patch?

I would very much like to see GIMP use CMake as its build system as well, having had a very positive experience with using CMake for projects such as http://fc-solve.shlomifish.org/ ,
https://bitbucket.org/shlomif/website-meta-language/overview , and http://www.shlomifish.org/rwlock/ . I've written about CMake’s advantages over GNU Autotools here:

http://www.shlomifish.org/open-source/anti/autohell/

In any case, I would be willing to work on porting GIMP's build system to CMake, as long as there is a general agreement from GIMP's developers that CMake will be available in addition or instead of GNU Autotools (so I won't work for naught).

Note that by this, I don't mean that I support the conversion of GIMP to Qt, which was the original poster’s other suggestion.

Regards,

Shlomi Fish

Hi Shlomi

On Sun, Jul 29, 2012 at 01:21:03PM +0300, Shlomi Fish wrote:

In any case, I would be willing to work on porting GIMP's build system to CMake, as long as there is a general agreement from GIMP's developers that CMake will be available in addition or instead of GNU Autotools (so I won't work for naught).

Automake has served GIMP well so far. We also have several people who know automake well enough to help other developers if they are unable to find their way. Do we need to change to CMake? Nobody has given reasons so far, just assumed that we'd like to switch to CMake. It would substitute one hell for another.

Same applies for Qt. These suggestions keep coming up again and again. GIMP should be rewritten in C++, GIMP should use some other new thing, etc. Many times I look at how GIMP does something (in its tree) as an example of how to do something nearly perfectly.

Mukund

On Sun, Jul 29, 2012 at 7:09 AM, Mukund Sivaraman wrote:

Hi Shlomi

On Sun, Jul 29, 2012 at 01:21:03PM +0300, Shlomi Fish wrote:

In any case, I would be willing to work on porting GIMP's build system to CMake, as long as there is a general agreement from GIMP's developers that CMake will be available in addition or instead of GNU Autotools (so I won't work for naught).

Automake has served GIMP well so far. We also have several people who know automake well enough to help other developers if they are unable to find their way. Do we need to change to CMake? Nobody has given reasons so far, just assumed that we'd like to switch to CMake. It would substitute one hell for another.

Same applies for Qt. These suggestions keep coming up again and again. GIMP should be rewritten in C++, GIMP should use some other new thing, etc. Many times I look at how GIMP does something (in its tree) as an example of how to do something nearly perfectly.

Mukund _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

I totally agree with Mukund. I sincerely hope that we continue with using GNU make which works extremely well as far as I am concerned.

Of course, if GIMP is re-written in qbasic that would be great. :) :) Maybe APL?

Hi Mukund,

On Sun, 29 Jul 2012 16:39:19 +0530 Mukund Sivaraman wrote:

Hi Shlomi

On Sun, Jul 29, 2012 at 01:21:03PM +0300, Shlomi Fish wrote:

In any case, I would be willing to work on porting GIMP's build system to CMake, as long as there is a general agreement from GIMP's developers that CMake will be available in addition or instead of GNU Autotools (so I won't work for naught).

Automake has served GIMP well so far.

I recall running into many problems with the Automake/Autoconf/libtool/etc. setup on many projects, including the breaking of a lot of backwards-compatibility and forward-compatibility. I don't recall anything specific with GIMP in particular, but it can happen.

We also have several people who
know automake well enough to help other developers if they are unable to find their way.

Well, I know CMake pretty well, and CMake is much easier to learn than Autohell. It took me less time to convert Freecell Solver’s build system from GNU Autotools to CMake than it did to originally autoconfiscate it (and that was with learning CMake on the fly and without knowing it beforehand). A different developer on Freenode's ##programming testified a similar experience with his own project.

Do we need to change to CMake? Nobody has given reasons so far, just assumed that we'd like to switch to CMake. It would substitute one hell for another.

Well, I have given many reasons here:

http://www.shlomifish.org/open-source/anti/autohell/

You should have followed and read the link.

This reminds me of Larry Wall's analogy of a ball in a local minima that can exert some effort into climbing a hill and then reaching an even lower pit where it will be happier (but thinks that the higher pit is fine).

And I should note that CMake is in no way a hell. I never really liked GNU Autotools but thought I needed to use it because that was the only sane solution. Then I discovered CMake and now I'm much happier.

BTW, we can keep the old Autotools-based setup for the time being in case we want it because it can co-exist along with the CMake-based one.

Same applies for Qt.

I never said I support switching GIMP to Qt.

These suggestions keep coming up again and again. GIMP should be rewritten in C++, GIMP should use some other new thing, etc. Many times I look at how GIMP does something (in its tree) as an example of how to do something nearly perfectly.

Well, we can keep the way GIMP does things as it is just fine and just add a CMake-based build system.

Regards,

Shlomi Fish

Hi Partha,

On Sun, 29 Jul 2012 07:22:35 -0400 Partha Bagchi wrote:

On Sun, Jul 29, 2012 at 7:09 AM, Mukund Sivaraman wrote:

Hi Shlomi

On Sun, Jul 29, 2012 at 01:21:03PM +0300, Shlomi Fish wrote:

In any case, I would be willing to work on porting GIMP's build system to CMake, as long as there is a general agreement from GIMP's developers that CMake will be available in addition or instead of GNU Autotools (so I won't work for naught).

Automake has served GIMP well so far. We also have several people who know automake well enough to help other developers if they are unable to find their way. Do we need to change to CMake? Nobody has given reasons so far, just assumed that we'd like to switch to CMake. It would substitute one hell for another.

Same applies for Qt. These suggestions keep coming up again and again. GIMP should be rewritten in C++, GIMP should use some other new thing, etc. Many times I look at how GIMP does something (in its tree) as an example of how to do something nearly perfectly.

Mukund _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

I totally agree with Mukund. I sincerely hope that we continue with using GNU make which works extremely well as far as I am concerned.

CMake can generate GNU make-compatible makefiles just fine, so unless you meant GNU Automake, that's not the issue. CMake can also generate project files for other IDEs and support some other build-systems, all from the same sources, so in this respect it is far superior to GNU Autohell.

Of course, if GIMP is re-written in qbasic that would be great. :) :) Maybe APL?

We should rewrite GIMP in PDP-10 Assembly: http://en.wikipedia.org/wiki/PDP-10 .

Regards,

Shlomi Fish

On Sun, Jul 29, 2012 at 02:51:44PM +0300, Shlomi Fish wrote:

Do we need to change to CMake? Nobody has given reasons so far, just assumed that we'd like to switch to CMake. It would substitute one hell for another.

Well, I have given many reasons here:

http://www.shlomifish.org/open-source/anti/autohell/

You should have followed and read the link.

I meant nobody had given reasons for what's wrong with GIMP's build system that would warrant a switch. You may dislike automake and find many faults in it, but it works for GIMP.

Mukund

On Sunday, July 29, 2012, 13:55:48, Shlomi Fish wrote:

CMake can generate GNU make-compatible makefiles just fine, so unless you meant GNU Automake, that's not the issue. CMake can also generate project files for other IDEs and support some other build-systems, all from the same sources, so in this respect it is far superior to GNU Autohell.

How well does CMake handle cross-compiling? I recently had to compile a few projects that didn't use autotools, and getting them to cross-compile wasn't fun (one of those made some very wrong assumptions about Windows as well, which didn't help either).

On Sun, Jul 29, 2012 at 8:25 AM, Jernej Simončič wrote:

On Sunday, July 29, 2012, 13:55:48, Shlomi Fish wrote:

CMake can generate GNU make-compatible makefiles just fine, so unless you meant GNU Automake, that's not the issue. CMake can also generate project files for other IDEs and support some other build-systems, all from the same sources, so in this respect it is far superior to GNU Autohell.

How well does CMake handle cross-compiling? I recently had to compile a few projects that didn't use autotools, and getting them to cross-compile wasn't fun (one of those made some very wrong assumptions about Windows as well, which didn't help either).

-- < Jernej Simončič ><><><><>< http://eternallybored.org/ >

Things equal to nothing else are equal to each other. -- First Postulate of Isomurphism

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

Exactly!! I for one definitely vote against such a change assuming my vote counts. :)

On Sun, 29 Jul 2012, Partha Bagchi wrote:

On Sun, Jul 29, 2012 at 8:25 AM, Jernej Simončič wrote:

On Sunday, July 29, 2012, 13:55:48, Shlomi Fish wrote:

CMake can generate GNU make-compatible makefiles just fine, so unless you meant GNU Automake, that's not the issue. CMake can also generate project files for other IDEs and support some other build-systems, all from the same sources, so in this respect it is far superior to GNU Autohell.

How well does CMake handle cross-compiling? I recently had to compile a few projects that didn't use autotools, and getting them to cross-compile wasn't fun (one of those made some very wrong assumptions about Windows as well, which didn't help either).

Exactly!! I for one definitely vote against such a change assuming my vote counts. :)

Just chipping in with some actual information: cmake does support cross-compiling quite well. See
http://www.cmake.org/Wiki/CMake_Cross_Compiling.

Boudewijn

On Sun, Jul 29, 2012 at 8:57 AM, Boudewijn Rempt wrote:

On Sun, 29 Jul 2012, Partha Bagchi wrote:

On Sun, Jul 29, 2012 at 8:25 AM, Jernej Simončič wrote:

On Sunday, July 29, 2012, 13:55:48, Shlomi Fish wrote:

CMake can generate GNU make-compatible makefiles just fine, so unless you meant
GNU Automake, that's not the issue. CMake can also generate project files for
other IDEs and support some other build-systems, all from the same sources, so
in this respect it is far superior to GNU Autohell.

How well does CMake handle cross-compiling? I recently had to compile a few projects that didn't use autotools, and getting them to cross-compile wasn't fun (one of those made some very wrong assumptions about Windows as well, which didn't help either).

Exactly!! I for one definitely vote against such a change assuming my vote counts. :)

Just chipping in with some actual information: cmake does support cross-compiling quite well. See
http://www.cmake.org/Wiki/CMake_Cross_Compiling.

Boudewijn _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

In the past I have found it to be way too much work for too little gain and hence don't wish to use it on Windows.

Autotools may be unpleasant to learn, but once it works, it works, and it works well for GIMP. If you were starting a new project then you might have grounds to think about picking an easier build tool, but why throw away all the work already put into GIMP's use of autotools because autotools is too confusing for you? You likely aren't going to be doing any huge modifications on the autotools files yourself, so why not let the people who know how to use it use what they like?

P.S. Qt is a miserable library, and it's C++. Switching to it would essentially require a complete rewrite of GIMP and wouldn't really improve anything in the end.

On Sun, Jul 29, 2012 at 9:45 AM, Partha Bagchi wrote:

On Sun, Jul 29, 2012 at 8:57 AM, Boudewijn Rempt wrote:

On Sun, 29 Jul 2012, Partha Bagchi wrote:

On Sun, Jul 29, 2012 at 8:25 AM, Jernej Simončič wrote:

On Sunday, July 29, 2012, 13:55:48, Shlomi Fish wrote:

CMake can generate GNU make-compatible makefiles just fine, so unless you meant
GNU Automake, that's not the issue. CMake can also generate project files for
other IDEs and support some other build-systems, all from the same sources, so
in this respect it is far superior to GNU Autohell.

How well does CMake handle cross-compiling? I recently had to compile a few projects that didn't use autotools, and getting them to cross-compile wasn't fun (one of those made some very wrong assumptions about Windows as well, which didn't help either).

Exactly!! I for one definitely vote against such a change assuming my vote counts. :)

Just chipping in with some actual information: cmake does support cross-compiling quite well. See
http://www.cmake.org/Wiki/CMake_Cross_Compiling.

Boudewijn _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

In the past I have found it to be way too much work for too little gain and hence don't wish to use it on Windows. _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Sunday, July 29, 2012, 14:57:17, Boudewijn Rempt wrote:

Just chipping in with some actual information: cmake does support cross-compiling quite well. See
http://www.cmake.org/Wiki/CMake_Cross_Compiling.

This looks very complicated compared to ./configure --host=x86_64-w64-mingw32 that autotools needs.

On 12-07-29 06:21 AM, Shlomi Fish wrote:

In any case, I would be willing to work on porting GIMP's build system to CMake, as long as there is a general agreement from GIMP's developers that CMake will be available in addition or instead of GNU Autotools (so I won't work for naught).

My one exposure to CMake was when I was fixing (and helping to fix) a build issue for Blender that had an experimental (but optional) feature.

My general impression was that I saw a general similarity to autofoo but it seemed as if it was a little simpler in some ways. One thing I definitely liked about it is being able to do multiple compiles of the program in to different sub-directories, each with a different enabled feature set. It allowed me to have both a git master version of Blender at the same time as a version that had the experimental feature compiled in. It made it easier to test the experimental version while still having a reasonably stable copy for regular use.

Date: Sun, 29 Jul 2012 14:55:48 +0300 From: shlomif@shlomifish.org
To: partha1b@gmail.com
CC: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] What about switching from Gtk+ to Qt

Hi Partha,

On Sun, 29 Jul 2012 07:22:35 -0400 Partha Bagchi wrote:

On Sun, Jul 29, 2012 at 7:09 AM, Mukund Sivaraman wrote: ...
Of course, if GIMP is re-written in qbasic that would be great. :) :) Maybe APL?

We should rewrite GIMP in PDP-10 Assembly: http://en.wikipedia.org/wiki/PDP-10 .

Regards,

Shlomi Fish

For some reason, this reminds me of last month when I began porting an old VB6 project of mine into VS2010 (made no easier by a mandatory import step through VS2008). I had to fix a thousand-plus build errors all by hand because the VB programming model had simply changed so much from VB6. The end result both runs nicer on the outside and looks nicer on the inside, but the transition itself was just plain hell.

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

On Monday, July 30, 2012, 9:06:53, Malix wrote:

Switching to new build system should not be linked to the fact that the former does not work, but to the best that the new works.

Except that looking at CMake documentation, it makes cross-compiling GIMP much more complicated that it's at the moment.

Qt is a great library. Yes is C++ but dosen't require rewriting GIMP but only the user interface. But as already said I shot too high :-)

...which still requires that nearly everything is rewritten anyway.

On 07/29/2012 05:17 AM, Mukund Sivaraman wrote:

On Sun, Jul 29, 2012 at 02:51:44PM +0300, Shlomi Fish wrote:

Do we need to change to CMake? Nobody has given reasons so far, just assumed that we'd like to switch to CMake. It would substitute one hell for another.

Well, I have given many reasons here:

http://www.shlomifish.org/open-source/anti/autohell/

You should have followed and read the link.

When I see terms like autohell I assume it's flame baiting and don't read it. I don't have time for un-civility. If someone can't make a point without using an ad-hominem attack I automatically assume they have no real point.

Patrick

Date: Fri, 3 Aug 2012 22:23:27 -0700 From: phorgan1@gmail.com
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] What about switching from Gtk+ to Qt

On 07/29/2012 05:17 AM, Mukund Sivaraman wrote:

On Sun, Jul 29, 2012 at 02:51:44PM +0300, Shlomi Fish wrote:

Do we need to change to CMake? Nobody has given reasons so far, just assumed that we'd like to switch to CMake. It would substitute one hell for another.

Well, I have given many reasons here:

http://www.shlomifish.org/open-source/anti/autohell/

You should have followed and read the link.

When I see terms like autohell I assume it's flame baiting and don't read it. I don't have time for un-civility. If someone can't make a point without using an ad-hominem attack I automatically assume they have no real point.

Patrick

I'm not sure it's (technically) ad hominem, but you're right that the epithet sounds more like flamebait than actual discussion.

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

Hi Patrick,

On Fri, 03 Aug 2012 22:23:27 -0700 Patrick Horgan wrote:

On 07/29/2012 05:17 AM, Mukund Sivaraman wrote:

On Sun, Jul 29, 2012 at 02:51:44PM +0300, Shlomi Fish wrote:

Do we need to change to CMake? Nobody has given reasons so far, just assumed that we'd like to switch to CMake. It would substitute one hell for another.

Well, I have given many reasons here:

http://www.shlomifish.org/open-source/anti/autohell/

You should have followed and read the link.

When I see terms like autohell I assume it's flame baiting and don't read it. I don't have time for un-civility. If someone can't make a point without using an ad-hominem attack I automatically assume they have no real point.

Well, calling GNU Autotools "Autohell" is not an ad-hominem attack. However, assuming that since I called it "Autohell" it is wrong (or "flamebait"), is. See:

http://en.wikipedia.org/wiki/Ad_hominem

Regards,

Shlomi Fish

On 08/04/2012 02:43 AM, Shlomi Fish wrote:

Hi Patrick,

...elision by patrick... Well, calling GNU Autotools "Autohell" is not an ad-hominem attack. However, assuming that since I called it "Autohell" it is wrong (or "flamebait"), is. See:

http://en.wikipedia.org/wiki/Ad_hominem

Lol! Look in that article under abusive. It is exactly ad-hominem. By doing a personal attack, calling it autohell, instead of having anything to say about why it's good or not, you exactly fulfill the definition of an ad-hominem attack.

Patrick

On 08/06/12 05:30, Patrick Horgan wrote:

On 08/04/2012 02:43 AM, Shlomi Fish wrote:

Hi Patrick,

...elision by patrick... Well, calling GNU Autotools "Autohell" is not an ad-hominem attack. However, assuming that since I called it "Autohell" it is wrong (or "flamebait"), is. See:

http://en.wikipedia.org/wiki/Ad_hominem

Lol! Look in that article under abusive. It is exactly ad-hominem. By doing a personal attack, calling it autohell, instead of having anything to say about why it's good or not, you exactly fulfill the definition of an ad-hominem attack.

Patrick

Patrick, you refer to a pseudo encyclopaedia but fail to read the very first line:

>> An ad hominem (Latin for "to the man") short for argumentum ad hominem, is an attempt to negate the truth of a claim by pointing out a negative characteristic or belief of the person supporting it.

Autotool, or whatever is a program, software. It is not a man and can not be the target of a _personal_ attack.

If someone finds a program "hellish" to use and calls it autohell, that is humouristic. It may lack a specific point but it can not be ad hom.

Enough.

Hi Patrick,

On Sun, 05 Aug 2012 20:30:29 -0700 Patrick Horgan wrote:

On 08/04/2012 02:43 AM, Shlomi Fish wrote:

Hi Patrick,

...elision by patrick... Well, calling GNU Autotools "Autohell" is not an ad-hominem attack. However, assuming that since I called it "Autohell" it is wrong (or "flamebait"), is. See:

http://en.wikipedia.org/wiki/Ad_hominem

Lol! Look in that article under abusive. It is exactly ad-hominem. By doing a personal attack, calling it autohell, instead of having anything to say about why it's good or not, you exactly fulfill the definition of an ad-hominem attack.

Well, I have looked in that article under abusive and I still don't see how my page constitutes of an ad-hominem attack just by the fact it calls GNU Autotools "Autohell".

An Ad-hominem attack has the following form:

1. Sophie says something.

2. Jack finds something questionable or wrong about Sophie herself.

3. Jack concludes that Sophie is wrong due to #2.

The Wikipedia page gives the following examples:

<<<< * "You can't believe John when he says the proposed policy would help the economy. He doesn't even have a job."

* "Candidate Jane's proposal about zoning is ridiculous. She was caught cheating on her taxes in 2003."

* "What would Mary know about fixing cars? She is a woman." (an example of Ad feminam)

* "What makes you so smart and all-knowing to deny God's existence? You haven't even finished school."

* "Your fashion opinion isn't valid, you can't even afford new shoes."

* "Your exposition is highly correct and valid, but you don't have enough academic degree" (an example of the Credential fallacy). [7]

Now my page ( http://www.shlomifish.org/open-source/anti/autohell/ ) gives many valid reasons why CMake is superior and GNU Autotools is inferior, and as a result concludes it is valid to nickname Autotools "Autohell" as a derogatory name, just based on their own deficiencies. So how does it consist of an ad-hominem attack?

Regards,

Shlomi Fish

On Mon, Aug 6, 2012 at 12:56 PM, Shlomi Fish wrote:

Well, I have looked in that article under abusive and I still don't see how my page constitutes of an ad-hominem attack just by the fact it calls GNU Autotools "Autohell".

I'm glad that you're having tons of fun discussing deep philosophical standpoints, but for the mere mortals... TL;DR: should I be adding "We like autotools and think you should apologize for calling them autohell" to our new FAQ?

Thanks.

Alexandre Prokoudine http://libregraphicsworld.org

Von: Alexandre Prokoudine

I'm glad that you're having tons of fun discussing deep philosophical standpoints, but for the mere mortals... TL;DR: should I be adding "We like autotools and think you should apologize for calling them autohell" to our new FAQ?

Add

"Occasionally, we get requests to port GIMP to a different programming language, a different toolkit or different build toolchain. If you came here to propose any of this, make sure that your proposal includes examples for shortcomings of the currently used things and benefits of your suggested solutions.

Keep in mind that GIMP is being built on several platforms, and we'd like to use the same programming language, toolkit and build tools on all of them. Your personal preferences will be irrelevant - you don't have to convince yourself to use your suggestions, you have to convince other people to do so."

Regards, Michael

On 08/05/2012 10:56 PM, gg wrote:

... elision by patrick ...

Patrick, you refer to a pseudo encyclopaedia but fail to read the very first line:

An ad hominem (Latin for "to the man") short for argumentum ad

hominem, is an attempt to negate the truth of a claim by pointing out a negative characteristic or belief of the person supporting it.

Autotool, or whatever is a program, software. It is not a man and can not be the target of a _personal_ attack.

In a way you are correct, although in this case the use of the term is directed at people not at software. The latin does refer to man, but it's the latin name for a particular style of rhetorical argument, usually considered a logical fallacy in debate. It's one where you attack the opponent rather than the opponent's argument.

In this case the opponent of course would be the gnu auto-configuration tools, and those who advocate for its use, the real target of the attack. By calling the tool suite by a pejorative name, it attacks those who advocate for it, in essence saying that there must be something wrong with them if they advocate for something which is so detestable that it does not even deserve to be called by its name. That's a pretty classical ad-hominem attack.

The author's use of the term is really intended to influence people, to let them know that he's convinced that the software suite forces one into a hell of use, and only someone who thought that was ok would advocate for it. (Obviously the software isn't going to care what it's called, the title is directed toward the reader;)

This is in contrast of course to someone who knows the tools and the contrasted tools well and can speak to the strengths and weaknesses of each and come to a reasoned judgment.

All this is to say that it weakens your argument to use personal attack. It makes you look like you consider your argument weak, so must resort to making your opponents, those who would support the tools, feel stupid.

My point is, that if someone doesn't consider their own argument strong and must stoop to attacking those who support the opposing idea, I figure it's not worth my time to read it.

Patrick

STOOOOOOP ITTTTTTTTTT

And don't you dare say "But he started it!".

On Mon, Aug 6, 2012 at 12:14 PM, Patrick Horgan wrote:

On 08/05/2012 10:56 PM, gg wrote:

... elision by patrick ...

Patrick, you refer to a pseudo encyclopaedia but fail to read the very first line:

An ad hominem (Latin for "to the man") short for argumentum ad

hominem, is an attempt to negate the truth of a claim by pointing out a negative characteristic or belief of the person supporting it.

Autotool, or whatever is a program, software. It is not a man and can not be the target of a _personal_ attack.

In a way you are correct, although in this case the use of the term is directed at people not at software. The latin does refer to man, but it's the latin name for a particular style of rhetorical argument, usually considered a logical fallacy in debate. It's one where you attack the opponent rather than the opponent's argument.

In this case the opponent of course would be the gnu auto-configuration tools, and those who advocate for its use, the real target of the attack. By calling the tool suite by a pejorative name, it attacks those who advocate for it, in essence saying that there must be something wrong with them if they advocate for something which is so detestable that it does not even deserve to be called by its name. That's a pretty classical ad-hominem attack.

The author's use of the term is really intended to influence people, to let them know that he's convinced that the software suite forces one into a hell of use, and only someone who thought that was ok would advocate for it. (Obviously the software isn't going to care what it's called, the title is directed toward the reader;)

This is in contrast of course to someone who knows the tools and the contrasted tools well and can speak to the strengths and weaknesses of each and come to a reasoned judgment.

All this is to say that it weakens your argument to use personal attack. It makes you look like you consider your argument weak, so must resort to making your opponents, those who would support the tools, feel stupid.

My point is, that if someone doesn't consider their own argument strong and must stoop to attacking those who support the opposing idea, I figure it's not worth my time to read it.

Patrick _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On 12-08-06 04:56 AM, Shlomi Fish wrote:

Now my page ( http://www.shlomifish.org/open-source/anti/autohell/ ) gives many valid reasons why CMake is superior and GNU Autotools is inferior, and as a result concludes it is valid to nickname Autotools "Autohell" as a derogatory name, just based on their own deficiencies.

Some good information on that web page, Shlomi. One comment about the page. It has a heading of "Disadvantages of GNU Autotools" but the points below start by mentioning an advantage of CMake instead of a disadvantage of the Autotools.

One advantage of CMake you didn't list is how it can do builds to a sub-directory of the source tree. I found this helpful when building a standard version of Blender and an experimental version with some added options without having to copy the entire source tree to a separate directory to do the two builds.

Based on my initial experience trying to learn how to use the GNU Autotools, the term "Autohell" seems appropriate. I found documentation on using it was hard to find and what I found was not that useful. A book I picked up from somewhere called "GNU Autoconf, Automake, and Libtool" helped a little but not that much. The main way I found to learn how to use the tools in the early days was by studying existing uses of the tools from various projects (ie. GIMP) and copying/modifying the files.

On Mon, 2012-08-06 at 13:42 -0400, Kevin Cozens wrote:

On 12-08-06 04:56 AM, Shlomi Fish wrote:

Now my page ( http://www.shlomifish.org/open-source/anti/autohell/ ) gives many valid reasons why CMake is superior and GNU Autotools is inferior, and as a result concludes it is valid to nickname Autotools "Autohell" as a derogatory name, just based on their own deficiencies.

Some good information on that web page, Shlomi. One comment about the page. It has a heading of "Disadvantages of GNU Autotools" but the points below start by mentioning an advantage of CMake instead of a disadvantage of the Autotools.

One advantage of CMake you didn't list is how it can do builds to a sub-directory of the source tree. I found this helpful when building a standard version of Blender and an experimental version with some added options without having to copy the entire source tree to a separate directory to do the two builds.

You can do that with autofoo as well, by calling the configure script from the sub-directory:

mkdir foo pushd foo
../configure ...
make ...
popd

Nils

Hi Malix

On Wed, Aug 08, 2012 at 09:24:37AM +0200, Malix wrote:

After my first post Alexandre ask to post a patch. From now I will have 2 weeks of vacation. So I will try to make it happen. As project kde did I will use am2cmake ruby script for automatic translation and the fix things by hand.
If someone else is interested let me know.

Please don't waste time on this. If you want to contribute, there are many other things that you could do for GIMP that are more essential. I don't think any of the developers will be interested in a CMake patch. It will go unused.

For a project as large as GIMP, use of any build system will be complicated. You will see similar complexity in an equivalent CMake config too. We already have a system that works well and has evolved to where it is today. There are more useful things to do.

Mukund

Hi Kevin

On Tue, Aug 07, 2012 at 05:04:33PM +0200, Nils Philippsen wrote:

One advantage of CMake you didn't list is how it can do builds to a sub-directory of the source tree. I found this helpful when building a standard version of Blender and an experimental version with some added options without having to copy the entire source tree to a separate directory to do the two builds.

You can do that with autofoo as well, by calling the configure script from the sub-directory:

mkdir foo pushd foo
../configure ...
make ...
popd

Adding to what Nils said, automake has the concept of srcdir and builddir. You'll find variables named similarly in Makefile.am files. These separate source code directory from the build effects directory.

Mukund