hi all,
building inkscape on os x fails today because :
In file included from extension/internal/pdf-cairo.cpp:52: extension/internal/pdf-cairo.h:28:19: error: cairo.h: No such file or directory extension/internal/pdf-cairo.h:29:30: error: pango/pangocairo.h: No such file or directory extension/internal/pdf-cairo.cpp:59:23: error: cairo-pdf.h: No such file or directory [...]
I don't have cairo on my system yet so this is not surprising but ./ configure lets me go into making without warning for anything. If not having cairo breaks the build there should be a configure check or a switch (--with[out]-cairo).
PS: in addition the link to the patch to cairo mentionned in the last thread about pdf printing with cairo http://lists.freedesktop.org/archives/cairo/2006-July/007477.htm gives me a 404 not found error.
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
On 31/07/06, jiho <jo.irisson@...400...> wrote:
hi all,
[...]
I don't have cairo on my system yet so this is not surprising but ./ configure lets me go into making without warning for anything. If not having cairo breaks the build there should be a configure check or a switch (--with[out]-cairo).
I am stuck on this as well. I was (or perhaps still am) intending to install the 'package' that provides cairo-pdf.h, so that I can get on, but this may be a bit tricky - the explanation is the same as the one on the page http://wiki.inkscape.org/wiki/index.php/NativeUIMacOsX - as the ability to provide the PDF backend is picked up automatically when configuring cairo.
Perhaps the short term solution is to wrap the problematic code in
#if FOR_THRILL_SEEKERS ... #endif
I agree that something in the configure script should select the back-end et cetera, but I am not sure what form this take. A fully automated test might be better than forcing the dev to fully understand what this is about.
Ben
jiho wrote:
hi all,
building inkscape on os x fails today because :
In file included from extension/internal/pdf-cairo.cpp:52: extension/internal/pdf-cairo.h:28:19: error: cairo.h: No such file or directory extension/internal/pdf-cairo.h:29:30: error: pango/pangocairo.h: No such file or directory extension/internal/pdf-cairo.cpp:59:23: error: cairo-pdf.h: No such file or directory [...]
I don't have cairo on my system yet so this is not surprising but ./ configure lets me go into making without warning for anything. If not having cairo breaks the build there should be a configure check or a switch (--with[out]-cairo).
I like the idea of the check. But really, IMHO, Cairo should be here to stay. So I'm less in favor of the switch. We have been talking about more integration with Cairo for a very, very long time. And not just for PDF. After 0.45 and according to the discussion we had earlier, we will start depending on gtk2.8, thus we will have a Cairo dependency anyway. So the check only needs to be around for a few months.
Just my 2pf again. Please ignore. I'll go back to my cave now. :-)
bob
On 31 Jul 2006, at 11:55 , Ben Fowler wrote:
On 31/07/06, jiho <jo.irisson@...400...> wrote:
hi all,
[...]
I don't have cairo on my system yet so this is not surprising but ./ configure lets me go into making without warning for anything. If not having cairo breaks the build there should be a configure check or a switch (--with[out]-cairo).
I am stuck on this as well. I was (or perhaps still am) intending to install the 'package' that provides cairo-pdf.h,
cairo-pdf.h is the header of cairo-pdf.cpp which is a source file of inkscape. so you have it. The problem is elsewhere in fact.
There are three problems IMHO: 1. local cairo headers (#include "...) are included instead of system ones (#include <...). I can understand this is usefull when using a local patched cairo but the defautl in the SVN source should be system libraries i.e. replace #include "cairo.h" #include "cairo-pdf.h" #include "cairo-ft.h" by #include <cairo.h> #include <cairo-pdf.h> #include <cairo-ft.h>
2. the presence of cairo is not checked in configure and appropriate include flags are not added to the compilation command. To use system wide header I therefore have to add: export CPPFLAGS="-I$FINK/include -I$FINK/include/cairo/" on OS X. (understand -I/usr/include/cairo/ on linux but maybe this path is checked for headers by default)
3. l.64: of cairo-pdf.cpp #ifdef USE_PANGO_CAIRO #include <pango/pangocairo.h> #endif and USE_PANGO_CAIRO is never defined. where does this come from? Even if it is not defined, the build requires pangocairo.h. I don't have pangocairo.h on my system and have no idea in which package it is at the moment (I have pango and pango-dev installed though so it is not in the base version). So this is what is holding the build right now.
Thanks for any help.
so that I can get on, but this may be a bit tricky - the explanation is the same as the one on the page http://wiki.inkscape.org/wiki/index.php/NativeUIMacOsX - as the ability to provide the PDF backend is picked up automatically when configuring cairo.
Perhaps the short term solution is to wrap the problematic code in
#if FOR_THRILL_SEEKERS ... #endif
I agree that something in the configure script should select the back-end et cetera, but I am not sure what form this take. A fully automated test might be better than forcing the dev to fully understand what this is about.
Ben
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php? page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Jean-Olivier Irisson --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- Personal address: Château St Martin, 66200 Elne, France Professional address: EPHE- UMR CNRS 8046, 52 av Paul Alduy, 66860 Perpignan Cedex, France
Mobile: 06 21 05 19 90 Web site: http://jo.irisson.free.fr/work/
On 31 Jul 2006, at 12:37 , Bob Jamison wrote:
jiho wrote:
hi all,
building inkscape on os x fails today because :
In file included from extension/internal/pdf-cairo.cpp:52: extension/internal/pdf-cairo.h:28:19: error: cairo.h: No such file or directory extension/internal/pdf-cairo.h:29:30: error: pango/pangocairo.h: No such file or directory extension/internal/pdf-cairo.cpp:59:23: error: cairo-pdf.h: No such file or directory [...]
I don't have cairo on my system yet so this is not surprising but ./ configure lets me go into making without warning for anything. If not having cairo breaks the build there should be a configure check or a switch (--with[out]-cairo).
I like the idea of the check. But really, IMHO, Cairo should be here to stay. So I'm less in favor of the switch. We have been talking about more integration with Cairo for a very, very long time. And not just for PDF. After 0.45 and according to the discussion we had earlier, we will start depending on gtk2.8, thus we will have a Cairo dependency anyway. So the check only needs to be around for a few months.
A check would be OK. I agree that talks about including cairo should become a reality and that it should stay. So forget the switch but please help with the check and other issues if you can :-)
Just my 2pf again. Please ignore. I'll go back to my cave now. :-)
bob
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
I'll look more at the problem before posting next time, promise. Here is some additional information:
On 31 Jul 2006, at 12:46 , jiho wrote:
On 31 Jul 2006, at 11:55 , Ben Fowler wrote:
On 31/07/06, jiho <jo.irisson@...400...> wrote:
[snip]
cairo-pdf.h is the header of cairo-pdf.cpp which is a source file of inkscape. so you have it. The problem is elsewhere in fact.
There are three problems IMHO:
- local cairo headers (#include "...) are included instead of
system ones (#include <...). I can understand this is usefull when using a local patched cairo but the defautl in the SVN source should be system libraries i.e. replace #include "cairo.h" #include "cairo-pdf.h" #include "cairo-ft.h" by #include <cairo.h> #include <cairo-pdf.h> #include <cairo-ft.h>
in cairo-pdf.h also l. 28 #include "cairo.h" >> #include <cairo.h>
- the presence of cairo is not checked in configure and
appropriate include flags are not added to the compilation command. To use system wide header I therefore have to add: export CPPFLAGS="-I$FINK/include -I$FINK/include/cairo/" on OS X. (understand -I/usr/include/cairo/ on linux but maybe this path is checked for headers by default)
- l.64: of cairo-pdf.cpp
#ifdef USE_PANGO_CAIRO #include <pango/pangocairo.h> #endif and USE_PANGO_CAIRO is never defined. where does this come from? Even if it is not defined, the build requires pangocairo.h. I don't have pangocairo.h on my system and have no idea in which package it is at the moment (I have pango and pango-dev installed though so it is not in the base version). So this is what is holding the build right now.
cairo-pdf.cpp l.52 #include "pdf-cairo.h"
l. 64-66 #ifdef USE_PANGO_CAIRO #include <pango/pangocairo.h> #endif
cairo-pdf.h l.29 #include <pango/pangocairo.h>
so pangocairo.h is included anyway, whatever the state of USE_PANGO_CAIRO. Not including it results in a compilation error: extension/internal/pdf-cairo.cpp:761: error: 'PANGO_GLYPH_EMPTY' was not declared in this scope extension/internal/pdf-cairo.cpp:761: error: 'PANGO_GLYPH_UNKNOWN_FLAG' was not declared in this scope so it seems mandatory. remove USE_PANGO_CAIRO? And I'm still stuck with this pangocairo.h which I cannot find. in which package is this on a linux box?
Thanks again.
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
jiho wrote:
cairo-pdf.h is the header of cairo-pdf.cpp which is a source file of inkscape. so you have it. The problem is elsewhere in fact.
There are three problems IMHO:
- local cairo headers (#include "...) are included instead of system
ones (#include <...). I can understand this is usefull when using a local patched cairo but the defautl in the SVN source should be system libraries i.e. replace #include "cairo.h" #include "cairo-pdf.h" #include "cairo-ft.h" by #include <cairo.h> #include <cairo-pdf.h> #include <cairo-ft.h>
Done
- the presence of cairo is not checked in configure and appropriate
include flags are not added to the compilation command. To use system wide header I therefore have to add: export CPPFLAGS="-I$FINK/include -I$FINK/include/cairo/" on OS X. (understand -I/usr/include/cairo/ on linux but maybe this path is checked for headers by default)
Someone on linux can add this, I think.
- l.64: of cairo-pdf.cpp
#ifdef USE_PANGO_CAIRO #include <pango/pangocairo.h> #endif and USE_PANGO_CAIRO is never defined. where does this come from? Even if it is not defined, the build requires pangocairo.h. I don't have pangocairo.h on my system and have no idea in which package it is at the moment (I have pango and pango-dev installed though so it is not in the base version). So this is what is holding the build right now.
(this is not my code, by the way) pango-cairo is a gtk2.8 thing, so I guess the switch is to allow compiling in <=2.6. It really should be HAVE_PANGO_CAIRO. That term would be generated by autoconf, thus the inclusion of config.h.
I think you mean pdf-cairo.cpp. Actually, if you look in pdf-cairo.h, the same include file is mentioned. So, since it is not switched, that is the "not found" you are seeing. That one can be removed, I think, and not having HAVE_PANGO_CAIRO defined should protect your compile from attempting to include the file you don't have.
I'll commit the changes to pdf-cairo.h/cpp
bob
On 31 Jul 2006, at 13:19 , Bob Jamison wrote:
jiho wrote:
cairo-pdf.h is the header of cairo-pdf.cpp which is a source file of inkscape. so you have it. The problem is elsewhere in fact.
There are three problems IMHO:
- local cairo headers (#include "...) are included instead of
system ones (#include <...). I can understand this is usefull when using a local patched cairo but the defautl in the SVN source should be system libraries i.e. replace #include "cairo.h" #include "cairo-pdf.h" #include "cairo-ft.h" by #include <cairo.h> #include <cairo-pdf.h> #include <cairo-ft.h>
Done
Thanks
- the presence of cairo is not checked in configure and
appropriate include flags are not added to the compilation command. To use system wide header I therefore have to add: export CPPFLAGS="-I$FINK/include -I$FINK/include/cairo/" on OS X. (understand -I/usr/include/cairo/ on linux but maybe this path is checked for headers by default)
Someone on linux can add this, I think.
In fact I think this is to be automated by automake or configure or something like this = by what generates all the -I flags on the compilation command line. Usually we just have export CPPFLAGS="-I$FINK/include" with $FINK=/sw on OS X and then all subpaths (such as -I/sw/include/libpng12 -I/sw/ include/glib-2.0 are generated at configure time).
- l.64: of cairo-pdf.cpp
#ifdef USE_PANGO_CAIRO #include <pango/pangocairo.h> #endif and USE_PANGO_CAIRO is never defined. where does this come from? Even if it is not defined, the build requires pangocairo.h. I don't have pangocairo.h on my system and have no idea in which package it is at the moment (I have pango and pango-dev installed though so it is not in the base version). So this is what is holding the build right now.
(this is not my code, by the way) pango-cairo is a gtk2.8 thing, so I guess the switch is to allow compiling in <=2.6. It really should be HAVE_PANGO_CAIRO. That term would be generated by autoconf, thus the inclusion of config.h.
I think you mean pdf-cairo.cpp. Actually, if you look in pdf-cairo.h, the same include file is mentioned. So, since it is not switched, that is the "not found" you are seeing. That one can be removed, I think, and not having HAVE_PANGO_CAIRO defined should protect your compile from attempting to include the file you don't have.
I've seen this but just after posting (and I added this in the next post, I'll definitely try more before posting). I used your commited changes and it works as expected (i.e. pangocairo.h is not requested) but then I hit the error I reported before, which seems due to the absence of pangocairo.h: extension/internal/pdf-cairo.cpp: In member function 'NR::Point Inkscape::Extension::Internal::PrintCairoPDF::draw_glyphs(cairo_t*, NR::Point, PangoFont*, PangoGlyphString*, bool, bool)': extension/internal/pdf-cairo.cpp:769: error: 'PANGO_GLYPH_EMPTY' was not declared in this scope extension/internal/pdf-cairo.cpp:769: error: 'PANGO_GLYPH_UNKNOWN_FLAG' was not declared in this scope
As pangocairo.h is a 2.8 thing and that switch to 2.8 was delayed to after 0.45 if I recall correctly, could a work around this dependency be found? (GTK+2.8 is not available on the mac currently)
Thanks again.
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
jiho wrote:
In fact I think this is to be automated by automake or configure or something like this = by what generates all the -I flags on the compilation command line. Usually we just have export CPPFLAGS="-I$FINK/include" with $FINK=/sw on OS X and then all subpaths (such as -I/sw/include/libpng12 -I/sw/ include/glib-2.0 are generated at configure time).
Since Cairo used pkg-config, it would simply be added to the PKG_CHECK_MODULES lines in configure.ac. Maybe something like this:
dnl ****************************** dnl Unconditional dependencies dnl ******************************
dnl *** NOTE: when we move to gtk 2.6 or later, we can remove the dnl ********* the override for g_ascii_strtod below... dnl sigc++-2.0 >= 2.0.12: using "visit_each" not available in 2.0.10 if test $cc_vers_major -gt 3; then PKG_CHECK_MODULES(INKSCAPE, gdkmm-2.4 glibmm-2.4 gtkmm-2.4 gtk+-2.0 >= 2.4.0 libxml-2.0 >= 2.6.11 libxslt >= 1.0.15 sigc++-2.0
= 2.0.12 cairo >= 1.0 $ink_spell_pkg gthread-2.0 >= 2.0 libpng >= 1.2)
else PKG_CHECK_MODULES(INKSCAPE, gdkmm-2.4 glibmm-2.4 gtkmm-2.4 gtk+-2.0 >= 2.4.0 libxml-2.0 >= 2.6.11 libxslt >= 1.0.15 sigc++-2.0
= 2.0.11 cairo >= 1.0 $ink_spell_pkg gthread-2.0 >= 2.0 libpng >= 1.2)
fi
On Mon, 2006-07-31 at 05:37 -0500, Bob Jamison wrote:
I like the idea of the check. But really, IMHO, Cairo should be here to stay.
So, could someone please add a pkg-config check for "cairo-pdf" (in addition to the one for "cairo")? It seems reasonable to disable the Cairo PDF stuff if the cairo-pdf pkg-config package isn't available, even while we continue to use main cairo.
-mental
On 31/07/06, MenTaLguY <mental@...3...> wrote:
On Mon, 2006-07-31 at 05:37 -0500, Bob Jamison wrote:
I like the idea of the check. But really, IMHO, Cairo should be here to stay.
So, could someone please add a pkg-config check for "cairo-pdf" (in addition to the one for "cairo")? It seems reasonable to disable the Cairo PDF stuff if the cairo-pdf pkg-config package isn't available, even while we continue to use main cairo.
See http://lwn.net/Articles/187757/ : if you have cairo-pdf, you should have a cairo-pdf.pc . (FWIW, I do not). This implies cairo 1.1.8 (or later) built with the pdf back-end.
Ben
On Mon, Jul 31, 2006 at 01:22:57PM -0400, MenTaLguY wrote:
On Mon, 2006-07-31 at 05:37 -0500, Bob Jamison wrote:
I like the idea of the check. But really, IMHO, Cairo should be here to stay.
So, could someone please add a pkg-config check for "cairo-pdf" (in addition to the one for "cairo")? It seems reasonable to disable the Cairo PDF stuff if the cairo-pdf pkg-config package isn't available, even while we continue to use main cairo.
Ditto!
What compilation flags are required for Cairo in order to get it to work?
Also, which version of Cairo is being developed against? 1.2.0? (Please do not develop against unreleased versions of Cairo, else we'll have a support nightmare when 0.45 comes out...)
Bryce
On Tue, 2006-08-01 at 11:34 -0700, Bryce Harrington wrote:
So, could someone please add a pkg-config check for "cairo-pdf" (in addition to the one for "cairo")? It seems reasonable to disable the Cairo PDF stuff if the cairo-pdf pkg-config package isn't available, even while we continue to use main cairo.
Ditto!
What compilation flags are required for Cairo in order to get it to work?
Isn't that what pkg-config is for? Let it tell us that at configure-time.
-mental
On Mon, 31 Jul 2006, jiho wrote:
extension/internal/pdf-cairo.cpp: In member function 'NR::Point Inkscape::Extension::Internal::PrintCairoPDF::draw_glyphs(cairo_t*, NR::Point, PangoFont*, PangoGlyphString*, bool, bool)': extension/internal/pdf-cairo.cpp:769: error: 'PANGO_GLYPH_EMPTY' was not declared in this scope extension/internal/pdf-cairo.cpp:769: error: 'PANGO_GLYPH_UNKNOWN_FLAG' was not declared in this scope
I still see this error on OS X, I believe it is due to the symbols themselves not being exported in this version of pango (1.10.1, the newest in fink) -- grep for PANGO_GLYPH_UNKNOWN_FLAG turned up nothing for the pango headers.
As far as I can tell, PANGO_GLYPH_EMPTY wasn't introduced until 1.11.6 and there was later discussion about its removal in favour of interface changes. So is there a more preferred replacement for the use of those symbols? If not, Inkscape probably needs to depend on a later version of Pango.
Cheers, Michael
On Tue, Aug 01, 2006 at 08:27:26PM -0400, MenTaLguY wrote:
On Tue, 2006-08-01 at 11:34 -0700, Bryce Harrington wrote:
So, could someone please add a pkg-config check for "cairo-pdf" (in addition to the one for "cairo")? It seems reasonable to disable the Cairo PDF stuff if the cairo-pdf pkg-config package isn't available, even while we continue to use main cairo.
Ditto!
What compilation flags are required for Cairo in order to get it to work?
Isn't that what pkg-config is for? Let it tell us that at configure-time.
Well, until such a time as pkg-config is giving this at compile time, I'd love to know what can be done manually to get it to work. ;-)
Bryce
Bryce Harrington wrote:
On Tue, Aug 01, 2006 at 08:27:26PM -0400, MenTaLguY wrote:
On Tue, 2006-08-01 at 11:34 -0700, Bryce Harrington wrote:
So, could someone please add a pkg-config check for "cairo-pdf" (in addition to the one for "cairo")? It seems reasonable to disable the Cairo PDF stuff if the cairo-pdf pkg-config package isn't available, even while we continue to use main cairo.
Ditto!
What compilation flags are required for Cairo in order to get it to work?
Isn't that what pkg-config is for? Let it tell us that at configure-time.
Well, until such a time as pkg-config is giving this at compile time, I'd love to know what can be done manually to get it to work. ;-)
Bryce
I think that cairo-pdf needs a test in configure.ac similar to pangoft2. However, you can always add it manually in the meantime with CFLAGS and LDFLAGS env CFLAGS="-I/usr/include/cairo" LDFLAGS="-L/usr/lib -lcairo" ./configure
...or wherever your cairo install lives.
bob
participants (6)
-
Ben Fowler -
Bob Jamison -
Bryce Harrington -
jiho -
MenTaLguY -
Michael Wybrow