headers
Jake Stride | 4 Dec 2003 15:27
Picon
Picon
Favicon

Problems Compiling refdb on FreeBSD

I am trying to compile refdb on freebsd but seem to be running into a few
problems, I have update my system but having configured refdb:

./configure --with-expat-lib=/usr/local/lib
--with-docbook-xsl=/usr/local/share/xsl/docbook
--with-classpath-root=/usr/local/share/java/classes
--with-refdb-url=http://localhost/refdb --with-db-server=pgsql

When running make I still cannot compile, I do have expat.h on my system:

lancelot# locate dbi.h
/usr/local/include/expat.h

But if I change the expat path to this dir, the config script bombs out. Has
anyone else had this problem/solved it?

Thanks

Jake

Lancelot# gmake
Making all in src
gmake[1]: Entering directory `/root/refdb-0.9.3/src'
source='refdbd.c' object='refdbd.o' libtool=no \
depfile='.deps/refdbd.Po' tmpdepfile='.deps/refdbd.TPo' \
depmode=none /usr/local/bin/bash .././conf/depcomp \
gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"refdb\"
-DVERSION=\"0.9.3\" -DREADLINE41=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruce D'Arcus | 4 Dec 2003 18:53

bibliographic templates for emacs


FYI, I've pout together some templates to simplify data entry in emacs.  
  More at:

http://netapps.muohio.edu/movabletype/archives/darcusb/darcusb/ 
000090.html

The templates are for mods, but are easily modified for risx.

Bruce

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Permalink | Reply | 0 comments |
headers
Markus Hoenicka | 4 Dec 2003 20:47
Picon

Problems Compiling refdb on FreeBSD

Hi Jake,

on FreeBSD the expat and libdbi headers end up in /usr/local/include
which is not in the default search path. Setting CFLAGS properly on
the configure command line fixes this problem. This is what I use on
my FreeBSD box (the -g is for debugging, you should not need it):

./configure --with-expat-lib=/usr/local/lib
--with-docbook-xsl=/usr/local/share/xsl/docbook
--with-tei-xsl=/usr/local/share/xsl/tei
--with-classpath-root=/usr/local/share/java/classes
--with-refdb-url=http://tipi.mininet/refdb --with-var-dir=/var/run
--with-log-dir=/var/log --with-db-server=sqlite
CFLAGS="-I/usr/local/include -g"

regards
Markus

Jake Stride writes:
 > I am trying to compile refdb on freebsd but seem to be running into a few
 > problems, I have update my system but having configured refdb:
 > 
 > ./configure --with-expat-lib=/usr/local/lib
 > --with-docbook-xsl=/usr/local/share/xsl/docbook
 > --with-classpath-root=/usr/local/share/java/classes
 > --with-refdb-url=http://localhost/refdb --with-db-server=pgsql
 > 
 > When running make I still cannot compile, I do have expat.h on my system:
 > 
 > lancelot# locate dbi.h
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Herbert | 9 Dec 2003 18:23
Picon
Picon

The case against <middlename>


               The (long) case against <middlename>

In brief
--------

Whereas the distinction between <firstname> and <lastname>, is quite
shared across different cultures, since it can easily and formally
defined as "given" name and "family" name, the notion of <middlename>
seems very culture-specific, and its inclusion in RISX brings more
issues than benefits. I suggest its suppression from the RISX DTD and
the refdb databases (just like in other similar formats)

If not completely suppressed, at least the parsing of RIS authors
should be simplified a lot in order to become predictable, and the
"clever" tricks with dots should be disabled.

Definition issue: what is a "middlename" actually?
--------------------------------------------------

In english, the middle name is a "second firstname", mainly used as
disambiguator.  It is more an extension of the <firstname> than a
first order part of the whole <author>. It may be only a nickname.

In french and spanish, a firstname can be a compound of several
"tokens" up to 3 or more.
<http://klamath.stanford.edu/~molinero/html/surname.html> Whereas in
english a middlename is generally of low importance, parts of a
compound firstname may be of equal importance and inseparable.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bruce D'Arcus | 9 Dec 2003 19:17

Re: The case against <middlename>

On Dec 9, 2003, at 12:23 PM, Marc Herbert wrote:

> Whereas the distinction between <firstname> and <lastname>, is quite
> shared across different cultures, since it can easily and formally
> defined as "given" name and "family" name, the notion of <middlename>
> seems very culture-specific, and its inclusion in RISX brings more
> issues than benefits. I suggest its suppression from the RISX DTD and
> the refdb databases (just like in other similar formats)

I tend to agree.  Quite an argument you've put together!

> * If I understand well (please confirm, Bruce?), MODS also only knows
> "family" and "given" as nameparts.
>   <http://www.loc.gov/standards/mods/mods-outline.html#name>
> I did not understand the meaning of the "date" attribute (thanks in
> advance for explaining), but I guess it is not equivalent to a
> middlename :-) BTW, I like the choice of "family" and "given" as
> attributes, they look very universal, and emphase the meaning as
> opposed to a somewhat controversial "position".

You've got it.  Putting it on an attribute also allows:

<namePart>United States</namePart>
<namePart>Senate</namePart>

 From my understanding, it makes sense to remove middlename from risx, 
and change first and last to family and given, to allow for later 
internationalization (think xml:lang) and MODS.  This took my awhile to 
get comfortable with being my main language is english, but it is the 
case that in many languages the first name is in fact the family name,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bruce D'Arcus | 9 Dec 2003 19:32

Re: The case against <middlename>


On Dec 9, 2003, at 12:23 PM, Marc Herbert wrote:

> 1) I think the best answer is: nothing. The tradition in the BibTeX
> world is:
>   But an author's complete name may be "Donald E. Knuth" or even
>   "J. P. Morgan"; you should type it the way the author would like it 
> to
>   appear, if that's known.

But this is complicated by the fact that presentation of names is style 
specific.  It becomes a huge PITA, actually, because generally Donald 
E. Knuth becomes "Knuth, D. E." in a bib entry, or just "Knuth, D."  
I've actually gone to some length to track down full first names for my 
DB.

Bruce

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Permalink | Reply | 0 comments |
headers
Bruce D'Arcus | 10 Dec 2003 00:24

compile problems

What does this mean?

checking for Perl module Text::Iconv... ./configure: line 5224: 17210 
Trace/BPT trap          $myperl -e 'use Text::Iconv;' >/dev/null 2>&1
configure: WARNING: Perl module Text::Iconv is required for some scripts

It -- along with problems compiling xml::parser -- seems to be majorly 
tripping up compilation of refdb on my laptop.

# make
Making all in src
source='refdbd.c' object='refdbd.o' libtool=no \
depfile='.deps/refdbd.Po' tmpdepfile='.deps/refdbd.TPo' \
depmode=none /bin/sh .././conf/depcomp \
gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"refdb\" 
-DVERSION=\"0.9.4-pre2\" -DREADLINE42=1 -DSTDC_HEADERS=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
-DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_FILE_H=1 
-DHAVE_SYS_TIME_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYSLOG_H=1 
-DHAVE_UNISTD_H=1 -DTIME_WITH_SYS_TIME=1 -DRETSIGTYPE=void 
-DHAVE_STRFTIME=1 -DHAVE_MKFIFO=1 -DHAVE_GETHOSTNAME=1 -DHAVE_SELECT=1 
-DHAVE_SOCKET=1 -DHAVE_STRCSPN=1 -DHAVE_STRSTR=1 -DHAVE_STRTOLL=1 
-DHAVE_ATOLL=1  -I. -I.  -DSYSCONFDIR=\"/usr/local/etc/refdb\" 
-DULLSPEC=\"%qu\"   -L/sw/lib -L/sw/lib/libdbi.0.0.5.dylib 
-L/sw/lib/libexpat.dylab -c `test -f refdbd.c || echo './'`refdbd.c
refdbd.c:40:54: dbi/dbi.h: No such file or directory
In file included from refdbd.c:49:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Markus Hoenicka | 10 Dec 2003 01:10
Picon

compile problems

Bruce D'Arcus writes:
 > What does this mean?
 > 
 > checking for Perl module Text::Iconv... ./configure: line 5224: 17210 
 > Trace/BPT trap          $myperl -e 'use Text::Iconv;' >/dev/null 2>&1
 > configure: WARNING: Perl module Text::Iconv is required for some scripts
 > 
 > It -- along with problems compiling xml::parser -- seems to be majorly 
 > tripping up compilation of refdb on my laptop.
 > 

No, the missing Text::Iconv module does not influence the compilation
of RefDB. It is explained in some detail at the end of the configure
output. In brief, if you don't have Text::Iconv handy, some Perl
scripts that rely on this module will fail to run (and they will tell
you so).

 > # make
[...]
 > refdbd.c:40:54: dbi/dbi.h: No such file or directory

This is the real problem that screws up your compilation. Most likely
the include files end up in a directory which is not in the default
search path of your compiler. Setting the CFLAGS variable on the
configure command line appropriately might fix the problem, like in:

./configure <your options> CFLAGS="-I/usr/local/include"

regards,
Markus
(Continue reading)

Permalink | Reply | 0 comments |
headers
Markus Hoenicka | 10 Dec 2003 02:05
Picon

The case against <middlename>

Marc Herbert writes:
 > Whereas the distinction between <firstname> and <lastname>, is quite
 > shared across different cultures, since it can easily and formally
 > defined as "given" name and "family" name, the notion of <middlename>
 > seems very culture-specific, and its inclusion in RISX brings more
 > issues than benefits. I suggest its suppression from the RISX DTD and
 > the refdb databases (just like in other similar formats)
 > 

Up-front: This is not going to happen.

 > In english, the middle name is a "second firstname", mainly used as
 > disambiguator.  It is more an extension of the <firstname> than a
 > first order part of the whole <author>. It may be only a nickname.
 > 

In American English, where the middle initial is probably used most
widely, the initial can also derive from the mothers maiden name or
any other family name. You can't treat this as part of the first name.

 > * RIS (!) does not have it
 > <http://www.refman.com/support/risformat_tags_02.asp>
 > 

They show a couple of middle initials and middle names in their examples.

 > * Formatting/sorting/... issues for subsequent operations
 > 
 > This is the apparent drawback. Suppressing an element means providing
 > less information to subsequent tools. However, I think lack of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Markus Hoenicka | 10 Dec 2003 02:08
Picon

Re: The case against <middlename>

Bruce D'Arcus writes:
 >  From my understanding, it makes sense to remove middlename from risx, 
 > and change first and last to family and given, to allow for later 
 > internationalization (think xml:lang) and MODS.  This took my awhile to 

As I've pointed out occasionally, I'm not religious about element
names. Changing first and last to family and given might be more
intuitive, given that "first" and "last" do not appear in this order
in some cultures.

However, the discussion about middlename forgets one fact that we
can't simply ignore. While it might be desirable to drop middlename in
order to make the markup more culture-agnostic, the main purpose of
RefDB is to format bibliographies according to publisher's
specifications. If you don't like middle names or middle initials,
you'll have to file a motion with the publishers of scientific
journals to remove these. In the life sciences approx. 99% of all
journals use middle names or middle initials regardless of the
cultural background of the authors. I've mentioned it previously that
my friend Raman (who insists that this is his full name) appears as
C.S. Raman on his papers for the sole purpose of having two initials.
RefDB must support middle names if it wants to be useful in the life
sciences.

regards,
Markus

--

-- 
Markus Hoenicka
markus.hoenicka <at> cats.de
(Continue reading)

Permalink | Reply | 2 comments |

Gmane