Hi,
David Neary [EMAIL PROTECTED] writes:
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
Hi,
Dave Neary [EMAIL PROTECTED] writes:
Do automake and libtool have any upcoming improvements that might
help with the pre-configure and linking stages that I should know
about?
Well, what versions are you using at the moment?
Sven
___
Hi,
Quoting Sven Neumann [EMAIL PROTECTED]:
Dave Neary [EMAIL PROTECTED] writes:
Do automake and libtool have any upcoming improvements that might
help with the pre-configure and linking stages that I should know
about?
Well, what versions are you using at the moment?
1.7 and 1.5
David Neary schrieb:
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
On Thu, 9 Sep 2004 00:06:12 +0200, David Neary [EMAIL PROTECTED] wrote:
Sven Neumann wrote:
David Neary [EMAIL PROTECTED] writes:
If everything ended up in one tarball, with a single-step build,
that would be grand. But I don't believe that's the intention,
given the precedents of GAP
On Thu, 09 Sep 2004 16:51:47 +0200, Michael Schumacher [EMAIL PROTECTED] wrote:
There's one aspect to splitting things out that hasn't been discussed
yet. By splitting e.g. a plug-in out into it's own module and basing it
on gimp-plug-in template, it becomes incredibly easy to compile it for
Hi,
Raphaël Quinet [EMAIL PROTECTED] writes:
This meta tarball would not be very hard to create or maintain: it's
just that the version numbers would have to be increased from time to
time, whenever the contents of a new gimp/gimp-gap/gimp-perl/... tarball
are extracted and included in the
Sven Neumann wrote:
I am not going to allow the source tree
to be clobbered with more stuff simply because we are too lazy to add
some simple notes to our web-site and FTP server. In the long run we
will want to split GIMP into even more packages.
Dave Neary wrote:
On another note, I'm not
Hi,
William Skaggs wrote:
Dave Neary wrote:
Splitting
stuff off feels an awful lot like putting it out to pasture. The
goal of just having the core application, with no plug-ins, no
image data structures, no scripts, and a minimum number of brushes,
patterns and gradients doesn't seem
Hi,
David Neary [EMAIL PROTECTED] writes:
If that's the case, we're working towards needing a jhbuild or a
garnome for the GIMP, which just doesn't seem right - we're a
desktop application, not a suite of developer libraries and
desktop applications. We have one set of developers, not
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
hello,
long ago when i had a job and a home and friends who were gimp
developers i had an idea of a plug-in building environment.
in the time that this environment was designed, i lost all of those
things previously listed. the environment i helped to design is now
being used successfully at
more,
On Wed, Sep 08, 2004 at 06:02:16PM -0700, Carol Spears wrote:
my experience with gimp is different than dave neary is talking about.
he is saying that if you dont get everything at one time, you will not
get it. when i first started to use gimp, it was so much fun to go
online and
13 matches
Mail list logo
