[Gambas-devel] xml.libxml 0.0.4

Benoit Minisini gambas at ...1...
Sun Oct 10 17:53:37 CEST 2004


On Sunday 10 October 2004 17:16, ron wrote:
>
> Thanks god, you didn't forget me :)
> And I'm not the only one having problems.
>
>
> The missing part for the components made by 3' party is
> the configure.in how the GB_COMPONENT should be.
>
> ==================
> This is what I have constructed till now:
> ------------------
> GB_COMPONENT(
>   xml,
>   XML,
>   [XML component],
>   [GB_FIND(xmlversion.h, /usr/local /usr, include include/libxml*
> include/libxml*/*)], [GB_FIND(libxml2.$SHLIBEXT, /usr/local /usr, lib)],
>   [$C_LIB -lxml])
>
>
> GB_COMPONENT(
>   curl,
>   CURL,
>   [Advanced networking component],
>   [GB_FIND(curl.h, `curl-config --prefix 2> /dev/null`, include)],
>   [GB_FIND(libcurl.$SHLIBEXT, `curl-config --prefix 2> /dev/null`, lib)],
>   [$C_LIB `curl-config --libs 2> /dev/null`])
>
>
> ==================
> what does it mean? (the way I interprete the lines)
> ------------------
>   [GB_FIND( <1> xmlversion.h, <2> /usr/local /usr, <3> include
> include/libxml* include/libxml*/*)],
>
> <1> xmlversion.h
>  A file to find to detect the -devel part is installed
>  Set by creator of component, what he find an appropiate file for it.

You can put several include files there. All them must be found in the 
following search paths.

>
> <2> /usr/local /usr
>  The paths to search in order to find, The /usr/local prefer if it is
>  done like I did, to not break SuSE compiled stuff.
>  By look first in the '/usr/local' the handle to use updated libraries
>  by user above the distribution pre compiled binaries problems like
>  I have withe SuSEs curl and xml should be solved.
>
>  This Search place can be done for curl with the shell function
>     `curl-config --prefix 2> /dev/null`
>
> <3> include include/libxml* include/libxml*/*
>   look in/for the 'include' directory
>     (or does it means it's count for the 'include' stuff)
>   for additional places 'include/libxml*' and 'include/libxml*/*'
>   to find the given *.h file.
>

Actually, the search path is a combination of <2> and <3>. <3> is a list of 
subdirectories.

For example, if <2> is "/usr /usr/local", and <3> is "include include/SDL*", 
then the includes will be search 
in /usr/include, /usr/include/SDL*, /usr/local/include 
and /usr/local/include/SDL*.

In other words, The search path is the product of <2> by <3>.

> -------------
>   [GB_FIND(<1> libxml2.$SHLIBEXT, <2> /usr/local /usr, <3> lib)],
>
> The same construction as above for the libraries
>
> -------------
>   [$C_LIB -lxml])
>
> This is the row giving me the problems.
> Daniel uses here some flags and that is what component distributors forget
> to say. The writer didn't provide it so using the wiki example I decided to
> use -lxml and set it to: '[$C_LIB -lxml]'
>
> Thanks god again I paste the 'curl' component also here to show how
> to get the lib and include directories.
> I see now the way how to get the flag with the same shell function is done
> :)
>
> In one of the other component the next rows are used
>   [$CXX_LIB $THREAD_LIB $X_LIBS -lqt-mt],
>   [$THREAD_INC])
> The unknown fact is why or when the 2 $THREAD_ are in need.
> Also not every component has '$C_LIB', resulting in the same question.
> That makes it importand the writer of the component add the complete
> GB_COMPONENT section to include in the configure.in.
>
>
> ====================
> I know, reading some files in the current source can give some answers.
> However the writer of the component can have here something HE decide
> and I cant guess what that is.
>
> My proposal to set this in files in the component directory and let it
> include by the ./configure to prevent the user has to type it in himself
> was not welcome by Benoit. His argument it is not so much work to
> add it yourself is true.
> But you must know the exact parameters to fill in to get it right.
>
> My view was that all the info need to add a component is inside 1
> directory. Simple add or remove that directory and ready.
>
> ====================
> The way as in the wiki looks good to me with the i.e. @LIBXML_DIR@ .
> However creators don't do it that way and use hardcoded parameters.
> When all is goes right then the configure phase takes care @LIBXML_DIR@
> have the right content.
>
> For the xml component I found 'xml2-config' now. (did guess it could have
> the same as curl) The results done from home directory:
>
> xml2-config --version
>   2.6.13
> xml2-config --prefix
>   /usr/local
> xml2-config --libs
>   -L/usr/local/lib -lxml2 -lz -lpthread -lm
> xml2-config --cflags
>   -I/usr/local/include/libxml2
>
> I know now the updated XML (and curl) is working.
>
> Now a try for the component could be:
> GB_COMPONENT(
>   xml,
>   XML,
>   [XML component],
>   [GB_FIND(xmlversion.h, `xml2-config --prefix 2> /dev/null`, include)],
>   [GB_FIND(libxml2.$SHLIBEXT, `xml2-config --prefix 2> /dev/null`, lib)],
>   [$C_LIB `xml2-config --libs 2> /dev/null`])
>
> *******************************
> in the Makefile.am is now.
> (I add the /local for my case extra in the paths)
>
> INCLUDES = -I$(top_srcdir)/src/share -I/usr/local/include/libxml2
>
> EXTRA_DIST = *.component
>
> pkglib_LTLIBRARIES = lib.gb.xml.libxml.la
>
> lib_gb_xml_libxml_la_LIBADD =
> lib_gb_xml_libxml_la_LDFLAGS = @LD_FLAGS@ -lxml2 -lpthread -lz -lm -lxslt
>
> lib_gb_xml_libxml_la_SOURCES = main.h main.c CXMLNode.h CXMLNode.c
> CXMLReader.h CXMLReader.c \ CXMLWriter.h CXMLWriter.c CXMLDocument.h
> CXMLDocument.c \ CXSLT.h CXSLT.c
>
>  install-exec-local:
>  @cp -f *.component $(pkglibdir)
>
> **************************************
> * This compiles with success !! yipie
> **************************************
> I do not have XML in the gambas help yet?
>
> So what can I do to be follow the wiki?
> I Changed to:
>
> INCLUDES = -I$(top_srcdir)/src/share @LIBXML_INC@
>
> EXTRA_DIST = *.component
>
> pkglib_LTLIBRARIES = lib.gb.xml.libxml.la
>
> lib_gb_xml_libxml_la_LIBADD =
> lib_gb_xml_libxml_la_LDFLAGS = @LD_FLAGS@ -lxml2 -lpthread -lz -lm -lxslt
>
> lib_gb_xml_libxml_la_SOURCES = main.h main.c CXMLNode.h CXMLNode.c
> CXMLReader.h CXMLReader.c \ CXMLWriter.h CXMLWriter.c CXMLDocument.h
> CXMLDocument.c \ CXSLT.h CXSLT.c
>
>  install-exec-local:
>  @cp -f *.component $(pkglibdir)
>
> ************************
> * When I use the @LIBXML_INC@ it goes wrong.
> * I get  Makefile:534: *** missing separator. Stop.
> ************************
>
> For the help, can it be the names are wrong?
>
> I look in the NET and CURL component
>   lib_gb_net_la_LIBADD = @NET_LIB@
>   lib_gb_net_la_LDFLAGS = @LD_FLAGS@
>   lib_gb_net_curl_la_LIBADD = @CURL_LIB@
>   lib_gb_net_curl_la_LDFLAGS = @LD_FLAGS@
> compare it to
>   lib_gb_xml_libxml_la_LIBADD =
>   lib_gb_xml_libxml_la_LDFLAGS = @LD_FLAGS@ -lxml2 -lpthread -lz -lm -lxslt
>
> This tells me I should have 'src/lib/xml/libxml' as path and not
> 'src/lib/libxml' I miss the between 'xml' directory. The logic in name
> giving is broke I think.
>
> How does that go Daniel?
> It is nice to have a general xml component with a libxml sub-component in
> it. Easy to add expat as second sub-component in future.
>
> I changed the 'lib_gb_xml_libxml' to 'lib_gb_libxml' in the files and
> in the file names.
>
> The RPC part is also not done yet.
>
> Using the same technics found sofar I add a GB_COMPONENT for RPC.
> Add a SUBDIRS line to the src/lib/libxml/Makefile.am
>
> Using now the hardcoded path instead @LIBXML_INC@
> reconf;configure;make and all is OK
> I find the '/opt/gambas/lib/gambas/lib.gb.libxml*' files and for the
> first time the '/opt/gambas/lib/gambas/lib.gb.libxml.rpc.*' files.
> make install and working but not in the help.
> /opt/gambas/share/gambas/info does not have the *.info and *.list files.
>
>
>
>
>
> I do not get the libxml.info and libxml.list files ?
> After done a 'gbi gb.xml.libxml' add it to ???
>
>
> Ron
>

There is a problem with the libxml component that prevent it to being 
"compilable" with gambas: the includes for the two different libraries libxml 
and libxslt are not in the same place. 

This is a case not managed by GB_COMPONENT() ! 

This was not a problem with the SDL component (that uses libsdl and 
libsdl_mixer), because all SDL includes are in the same directory.

As I said before, maybe Daniel could remove xslt things from libxml to put 
them in another component (gb.xml.libxml.xslt ?). So the problem will be 
fixed, and I will be able to compile it cleanly.

But if there is an explicit need for libxslt in the component, the problem 
will remain...

I have another problem on Mandrake:

xml2-config returns the correct information, but not xslt-config! It tells me 
that the xslt includes are in /usr/include/libxml2, and they are actually 
in /usr/include/libxslt! Maybe a Mandrake bug ?

Waiting for your answer, Daniel ! :-)

Regards,

-- 
Benoit Minisini
mailto:gambas at ...1...




More information about the Devel mailing list