Re: [Gimp-developer] on splitting things off

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sven

Sven Neumann wrote:
> I don't see what's wrong with needing a jhbuild type of script to ease
> compilation (not that I have ever felt the need to use jhbuild). GIMP
> is not a desktop application. It is (or should become if it isn't yet)
> an image manipulation suite. We have several sets of developers
> already and I hope that sooner or later it will be several dozens of
> them. If you are lacking this vision, you are effectively stalling
> GIMP development.

So do I (hope that some day we will have dozens of developer
groups). I like the idea of splitting the project up in terms of
domains of responsibility. That was the whole idea behind having
plug-in maintainers. I'm just not sure we have the same ideas
about how to get there. Then again, my ideas on the issue are
pretty blurred right now. I should maybe sit down and try to
clarify the way I think things might happen.

> Dave, it was you who only yesterday complained about the time that it
> takes to build GIMP.

Small correction - IO was complaining about how shit my computer
is. The GIMP's compile time is simply a symptom of that.

> Now imagine how much time it would take if GAP
> and gimp-perl were still in there. We are already way beyond the point
> where the GIMP tarball is handable. It takes hours to run make
> distcheck in this beast. It takes hours to check it out of CVS and
> build it. It takes hours to do a release, most of this due to the huge
> size of the tarball and the shear amount of files that need to be
> tagged and committed.

I agree, build time is a big issue. But you've said that most
people will have everything anyway, so how does build time
improve? Is the idea that if we don't change the API or API for
libgimp that you could recompile the core without recompiling
gimp-plug-ins? I guess that idea could work... 

But compile time has doubled over the past couple of years
without a huge change in the size of the source code. It seems to
me that the build tools we use have gotten more i/o and more
processor intensive. Is it possible we could make improvements
there? 

I'm not opposed to having stuff split off, but I am worried about
the stuff getting a bit lost. Most gimp 2.0 installs (the vast
majority, I would say) don't have GAP or the perl bindings
installed. That's not a trend we should be encouraging, IMHO. In
fact, I think we need to work out ways to actively discourage it,
and make sure most people have those packages (and others)
installed. I'm just not sure how to do that (as I said before).

Cheers,
Dave.

-- 
        David Neary,
        Lyon, France
   E-Mail: bolsh@xxxxxxxx
CV: http://dneary.free.fr/CV/

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux