From robin.berjon at expway.fr Tue Feb 15 10:05:22 2005
From: robin.berjon at expway.fr (Robin Berjon)
Date: Tue Feb 15 10:05:02 2005
Subject: [Dahut-pm] Redland on OSX
Message-ID: <421239E2.5000701@expway.fr>
Dahut!
I'm trying to build Redland on OSX with the (now faint) hope of playing
with my stupid ideas of RDF VFSs and other such silly things. Oh, and to
be cool too. But Redland's being uncool to me.
It dies when trying to build Raptor, thusly (looks long when wrapped but
is really two commands - the second one is kicked off by the first, but
produces the same error on its own):
/bin/sh ./libtool --mode=link --tag=CC gcc -g -O2 -g -O2 -o
libraptor.la -rpath /usr/local/lib -version-info 2:0:1 raptor_parse.lo
raptor_serialize.lo raptor_serialize_rdfxmla.lo raptor_rfc2396.lo
raptor_uri.lo raptor_locator.lo raptor_namespace.lo raptor_qname.lo
raptor_feature.lo raptor_general.lo raptor_utf8.lo raptor_www.lo
raptor_identifier.lo raptor_sequence.lo raptor_stringbuffer.lo
raptor_iostream.lo raptor_rdfxml.lo raptor_xml.lo raptor_xml_writer.lo
raptor_sax2.lo raptor_set.lo raptor_libxml.lo turtle_lexer.lo
turtle_parser.lo ntriples_parse.lo raptor_rss.lo raptor_nfc_data.lo
raptor_nfc.lo strcasecmp.lo raptor_www_libxml.lo -L/usr/local/lib -lxml2
-lz -lpthread -liconv -lm
gcc -dynamiclib -flat_namespace -undefined suppress -o
.libs/libraptor.1.1.0.dylib .libs/raptor_parse.o
.libs/raptor_serialize.o .libs/raptor_serialize_rdfxmla.o
.libs/raptor_rfc2396.o .libs/raptor_uri.o .libs/raptor_locator.o
.libs/raptor_namespace.o .libs/raptor_qname.o .libs/raptor_feature.o
.libs/raptor_general.o .libs/raptor_utf8.o .libs/raptor_www.o
.libs/raptor_identifier.o .libs/raptor_sequence.o
.libs/raptor_stringbuffer.o .libs/raptor_iostream.o
.libs/raptor_rdfxml.o .libs/raptor_xml.o .libs/raptor_xml_writer.o
.libs/raptor_sax2.o .libs/raptor_set.o .libs/raptor_libxml.o
.libs/turtle_lexer.o .libs/turtle_parser.o .libs/ntriples_parse.o
.libs/raptor_rss.o .libs/raptor_nfc_data.o .libs/raptor_nfc.o
.libs/strcasecmp.o .libs/raptor_www_libxml.o -L/usr/local/lib
/usr/local/lib/libxml2.dylib /usr/lib/libm.dylib -lz -lpthread
/usr/lib/libiconv.dylib -lm -install_name
/usr/local/lib/libraptor.1.dylib -compatibility_version 3
-current_version 3.0
*** Warning: inferring the mode of operation is deprecated.
*** Future versions of Libtool will require -mode=MODE be specified.
libtool: warning: cannot infer operation mode from `ppc'
libtool: you must specify a MODE
Try `libtool --help' for more information.
make[3]: *** [libraptor.la] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
I've tried all the hackery directly inside the generated libtool and the
Makefiles that I could muster, but to no avail. I've also tried to build
Raptor separately but I get the same result.
Any thoughts?
--
Robin Berjon
Research Scientist
Expway, http://expway.com/
From JGSmith at TAMU.Edu Mon Feb 21 09:11:20 2005
From: JGSmith at TAMU.Edu (James G Smith)
Date: Mon Feb 21 09:11:34 2005
Subject: [Dahut-pm] [RFC] XML Compiler Compiler
Message-ID: <200502211711.j1LHBKkQ004970@moya.tamu.edu>
Due to issues at work (new manager :/), I haven't been able to work
on the Gestinanna framework since OSCon last year. But things have
settled down a bit and I'm wanting to get back to it some.
The core piece that seemed most interesting to others was the XML
compiler that could generate Perl code given a description of an
application. As with XSP, taglibs extended the language and provided
the glue between the controller and the model.
Part of the problem was that the taglibs were hand-coded as part of a
SAX framework. This is nice for those of us that understand such
things, but for the average programmer that just wants to create an
extension, it might be a bit daunting. If nothing else, there's a
fairly steep learning curve (XSP solved a lot of this with their base
taglib package that works well for that environment).
Since taglibs extend the language (or can provide the language) and
they are XML, I figured I should be able to describe the XML schema
that the taglib defines, what the tags can be compiled to, and let an
XML Compiler Compiler generate the actual compiler for the taglib.
We're familiar with Yacc and its relatives and the BNF they consume.
The equivalent in the XML world seems to be RelaxNG with a few
modifications.
One aspect of XML that is different than languages Yacc works with is
that XML elements can be in one of at least two contexts: block and
expression. An expression results in a value that is used by the
parent element. A block either does not or is not expected to
produce a value. This distinction isn't important when writing XML,
but only when compiling into a language that makes a distinction
between the two in its grammer.
For example, if we have the fragment
...
with some children, then in a block context, it would be translated to
foreach my $x ( @people ) { ... }
but in an expression context, it would be translated to
map { ... } @people
since the result of a map is a value that can be used again.
This complicates the compiler definition since it must keep track of
which context a given element is in -- and that context is dependent
on the element's ancestors.
There are other dependencies on the context as well. For example, in
Perl, the statement separater is a semi-colon in a block context, but
a comma in an expression context.
This dependence on context makes writing taglibs a bit more
complicated than you might expect based on XSP.
Because of this dependence, I am thinking about making the
compilation instructions a bit more abstrace than verbatim Perl.
This has two benefits: the taglib writer doesn't have to worry about
context, and the compiler compiler can write compilers targeting
different languages if there is no verbatim code being emitted by the
compiler (in the compiler definition -- not the compiled compiler).
As an example: