On 2007-02-10 09:27:32 -0800 Nicola Pero
<[EMAIL PROTECTED]> wrote:
a quick test of a makefile executing pkg-config 1000 times takes
about 6
seconds..
say there are 5 invocations of pkg-config per invocation of make...
thats
200 make processes.
Wow - that would be a massive overhead ... for just reading config
(ie, doing
nothing
useful, only bootstrapping)! ;-)
I thought in the worst case scenario you'd run 1 pkg-config
invocation per
makefile -- that
would be pretty bad already since you're doubling the number of
processes
executed when
typing 'make' in an already built tree; but if you plan on adding 5
per
makefile invocation,
then you're almost multiplying by 6 the overhead of the building
system. In
practice
it will be less than that, but a x2 or x3 sounds perfectly plausible.
Yes.... there would only be one, unless we wanted to get rid of
GNUstep.conf entirely
then there would be about 5... you had reservations that GNUstep.conf
and gnustep.pc
contained duplicate information... since theres no way to get what i'm
trying to achieve from
GNUstep.conf, the only way around that would be to move everything in
there to gnustep.pc.
thats where the 5 per makefile invocations come from.
If we retain GNUstep.conf and add gnustep.pc we only need 1...
I consider that unacceptable considering we don't gain anything in
functionality, and
the improvement in 'standardization' is extremely doubtful.
Of course we don't gain anything,
getting rid of GNUSTEP_MAKEFILES isn't anything...
ability to get information about GNUstep from the shell isn't anything
if we want a decent -config system, we're going to reimplement
pkg-config...
on my system i have over 300 pkg-config enabled libraries... and i'm
glad I
don't have
300 foo-config scripts in my $PATH.
They are different things ... GNUstep has got a single config script
for
everything.
We don't install a config file for each library.
This was an attempt to state that if everyone created their own
-config system
which if GNUstep.sh/environment variables goes away i strongly believe
we
need. I would have 300 -config systems on my machine.
If you are obsessed with using pkg-config for GNUstep, then it would
make
sense to
install a pkg-config config file for each library that we install ...
so you
would have
a pkg-config configuration for libgnustep-base, libgnustep-gui, etc.
Then
people using
pkg-config instead of gnustep-make to build their software could at
least use
them in
the way they are intended to be used.
Still, I can't see any advantage in using pkg-config instead of
gnustep-make,
so I don't
really understand why anyone would want to do that. You'd be on your
own in
the nightmare
of how to compile or link your framework on all different machines
and
platforms.
that is not what i'm trying to do.... I'm attempting to *USE*
pkg-config
WITH gnustep-make not instead of. pkg-config does not replace
configure/make even on gnome/gtk it provides a way to query information
about the installed packages for use WITH make.
I think this would be a step in the right direction but everybody
has
already been down
that road and since then switched to pkg-config.
I don't see the parallel.
We are following a completely different road than everyone else - we
have a
centralized, standardized building system, a centralized,
standardized core
ObjC API, a centralized,
standardized GUI API, and everything else is built ordinately on top
of that
by the
same organized building system. ;-)
at the possibility of repeating myself It is not always possible to
use gnustep-make.
configure scripts and plugins for existing projects with existing
build systems..
without environment variables, or a -config system there is no way to
build a
GNUstep enabled gnuplot without converting its entire build system to
GNUstep-make this wouldn't fly.
Other people don't have that. Each library is built in a different
way and
installed
in the different way with different options; each library is using a
different subset
of libc and other system libraries, which vary a lot between
different
systems; it's
a mess with millions of non-standard flags and locations and conf
options and
system
dependent flags to determine and use. :-(
So, some of them figured out they'd put each library's flags into
some common
format
to put some order in the mess. Fine.
But we don't have that problem. We have organized and standardized
everything. Our system
is certainly "unusual", but well-organized and laid out. It's a
pleasure to
write your
quick GNUmakefile listing what goes into your library, knowing that
you don't
have to
do anything and it will just work on GNU/Linux/*BSD/Windows/Apple.
The usual
libc/compatibility/flags nightmare does not exist in our organized
world.
So saying that we're going through the road of everyone else is
inaccurate to
say the least.
We're not planning to have a config file per library. We just have a
plain-text file
where we put a key=value list of basic system-wide GNUstep
configuration.
I don't care about a config file per library... libraries which are
built with GNUstep-make
aren't hiding any information. gnustep-make has information only it
can find.
So, yes, our solutions might be different. GNUstep is different.
The only
objection to
GNUstep.conf I heard up to now is that "it's not the way the gnome
stores
config". I don't
see the point. Apache stores config in httpd.conf, including paths
to
resources or web pages.
So what's the big deal. It's what is appropriate for them to do.
The only objection i've heard from gnustep.pc is "Its not the way
GNUstep stores information".
The objection i have with GNUstep.conf is it isolates gnustep from the
rest of the world.
It sure is easy to use from shell scripts.... but how are you
supposed to find it when
it could be anywhere, somewhere only gnustep can find.
We cannot have a build system where information is only available to
GNUstep-make.
I don't really care if GNUstep-make does its own thing... GNUmakefiles
are really nice and
I agree, but it must play nice with the rest of the world.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev