2. Build GRASS:
o compile everything, incl NVIZ without PG (note, no ";" to
be used):
CFLAGS=-O2 LDFLAGS="-s" ./configure --without-postgres
make
The question is: why to exclude postgres support?
Sergiusz
--
http://ibiblio.org/ser/ | http://it-zone.org/
_________________________________________________________
tldp.org|gnu.org|hyperreal.info|pld-linux.org|it-zone.org
"The moon is made of green cheese." -- John Heywood
Hi Sergiusz
On Sun, Jun 16, 2002 at 07:33:10PM +0200, --s+ wrote:
2. Build GRASS:
you mean the release-docs,right?
o compile everything, incl NVIZ without PG (note, no ";" to
be used):
CFLAGS=-O2 LDFLAGS="-s" ./configure --without-postgres
make
Because often people do not have the PG libs installed. We had
that problem with a release in the past, that's why we decided
to go for the "minimum" impact compilation to enable
everybody to use NVIZ.
Note that for *.pg compilation PG must be enabled again (see release-doc).
Markus
--->[Quoting Markus Neteler <neteler@itc.it>:]
you mean the release-docs,right?
yeah - release_rules.txt
> o compile everything, incl NVIZ without PG (note, no ";" to
> be used):
> CFLAGS=-O2 LDFLAGS="-s" ./configure --without-postgres
> makeBecause often people do not have the PG libs installed. We had
that problem with a release in the past, that's why we decided
to go for the "minimum" impact compilation to enable
everybody to use NVIZ.
Ok - so what do you think about releasing several sets
of grass binaries - with different libraries compiled in?
Sergiusz
--
http://ibiblio.org/ser/ | http://it-zone.org/
_________________________________________________________
tldp.org|gnu.org|hyperreal.info|pld-linux.org|it-zone.org
"The moon is made of green cheese." -- John Heywood
Sergiusz Pawlowicz wrote:
> > o compile everything, incl NVIZ without PG (note, no ";" to
> > be used):
> > CFLAGS=-O2 LDFLAGS="-s" ./configure --without-postgres
> > make
>
> Because often people do not have the PG libs installed. We had
> that problem with a release in the past, that's why we decided
> to go for the "minimum" impact compilation to enable
> everybody to use NVIZ.Ok - so what do you think about releasing several sets
of grass binaries - with different libraries compiled in?
There isn't any real need.
The key issue is NVIZ. It can be built with or without PostgreSQL
support. If it's built with PostgreSQL support, it won't work at all
on systems which don't have libpq.
I'm not aware of any other programs which (currently) have optional
library dependencies. If they require a particular library, they
absolutely *require* it.
There may be a few cases where a library could be made optional, e.g.
+ NVIZ
Sergiusz Pawlowicz wrote:
> > o compile everything, incl NVIZ without PG (note, no ";" to
> > be used):
> > CFLAGS=-O2 LDFLAGS="-s" ./configure --without-postgres
> > make
>
> Because often people do not have the PG libs installed. We had
> that problem with a release in the past, that's why we decided
> to go for the "minimum" impact compilation to enable
> everybody to use NVIZ.Ok - so what do you think about releasing several sets
of grass binaries - with different libraries compiled in?
Mostly, there isn't any real need. We supply everything, and the user
gets to use anything for which they have the necessary libraries.
The key issue is NVIZ. It can be built with or without PostgreSQL
support. If it's built with PostgreSQL support, it won't work at all
on systems which don't have libpq. So, we supply NVIZ without
PostgreSQL support; it might be worthwhile supply a PostgreSQL enabled
version of NVIZ as an add-on.
I'm not aware of any other cases where a library dependency is
optional, but there may be a few cases where this should change, e.g.
+ NVIZ requires libtiff, but would still be usable without TIFF
export; it supports PPM export without any additional libraries.
However, inclusion of src/libes/ogsf/gsd_img_tif.c would need to be
conditionalised upon the availability of libtiff.
+ d.text.freetype uses the iconv functions if they are available; this
may introduce a dependency upon libiconv (but not on GNU systems,
where iconv() etc are in libc).
TIFF and iconv should probably be made configure options, rather than
being required (OGSF/TIFF) or used automatically when present
(d.text.freetype/iconv).
Another option would be to provide additional binaries which have been
statically linked against any non-standard libraries.
--
Glynn Clements <glynn.clements@virgin.net>
On Jun 17, Glynn Clements wrote:
> > Ok - so what do you think about releasing several sets
> > of grass binaries - with different libraries compiled in?
>
> Mostly, there isn't any real need. We supply everything, and the user
> gets to use anything for which they have the necessary libraries.
I agree that that's the right model.
One current frustration is that most optional functionality defaults
to being included in the configure script.
I recently experienced the following in trying to build grass:
1) run ./configure [...]
2) It complains about a missing library "foo"
3) Do one of the following:
a) install libfoo
b) add --without-foo to the configure command line
4) goto 1
I iterated on this 6 or 7 times I think. It was frustrating since the
configure script takes so long to run, (and I happened to not need any
of the functionality that wasn't available to start with).
What I would prefer is that if configure notices that some optional
functionality "foo" is not available, it automatically continues as if
the --without-foo option had been passed.
Of course, if this were in place, it might also be nice to add some
text to the final block of configure output that describes what
functionality would not be built so that the user could then install
additional libraries and rebuild as needed.
That would also be beneficial for the users that did want all the
functionality, since it would tell them in one step what additional
libraries would be necessary before building.
-Carl
--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725
Carl Worth wrote:
> > Ok - so what do you think about releasing several sets
> > of grass binaries - with different libraries compiled in?
>
> Mostly, there isn't any real need. We supply everything, and the user
> gets to use anything for which they have the necessary libraries.I agree that that's the right model.
One current frustration is that most optional functionality defaults
to being included in the configure script.
This was done intentionally.
The configure script used to generate warnings about the absence of
optional libraries. However, users didn't notice the warnings, then
filed "bug" reports about the corresponding modules not being built.
So, it was decided (not by me) that failure to detect an optional
library would result in a fatal error unless that functionality was
explicitly disabled.
--
Glynn Clements <glynn.clements@virgin.net>