Problem compiling experimental with CMake
by Liam White
Apologies for the wall of text.
liam@...3128...:/home/inkrepo$ cd experimental
liam@...3128...:/home/inkrepo/experimental$ ls
liam@...3128...:/home/inkrepo/experimental$ cmake .
-- Creating build files in: /home/inkrepo/experimental
-- Found GSL: /usr/lib/libgsl.so
-- Found BoehmGC: /usr/lib/x86_64-linux-gnu/libgc.so
-- Found poppler: /usr/lib/x86_64-linux-gnu/libpoppler.so
-- Found poppler-glib: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so
-- Found cairo-svg: /usr/lib/x86_64-linux-gnu/libcairo.so
-- Found poppler-cairo: /usr/lib/x86_64-linux-gnu/libcairo.so
-- checking for module 'libwpg-0.1'
-- package 'libwpg-0.1' not found
-- checking for module 'libwpg-stream-0.1'
-- package 'libwpg-stream-0.1' not found
-- checking for module 'libwpd-0.8'
-- package 'libwpd-0.8' not found
-- Found libwpg-0.2: /usr/lib/libwpg-0.2.so
-- Found libwpd-0.9: /usr/lib/libwpd-0.9.so
-- Found libwpd-stream-0.9: /usr/lib/libwpd-stream-0.9.so
-- Found Popt: /usr/lib/x86_64-linux-gnu/libpopt.so
-- Boost version: 1.54.0
-- checking for module 'gtkspell-2.0'
-- package 'gtkspell-2.0' not found
-- Try OpenMP C flag = [ ]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [/openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-Qopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-xopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [+Oopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-qsmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-mp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [ ]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [/openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-Qopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-xopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [+Oopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-qsmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-mp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Could NOT find OpenMP (missing: OpenMP_C_FLAGS OpenMP_CXX_FLAGS)
-- Generating header and sourcefiles from sp-marshal.list (Glib-Marshal)
-- sp-marshal.h unchanged
CMake Error: The following variables are used in this project, but they are
set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake
files:
ImageMagick_MagickCore_INCLUDE_DIR
used as include directory in directory /home/inkrepo/experimental
used as include directory in directory /home/inkrepo/experimental
used as include directory in directory /home/inkrepo/experimental/src
used as include directory in directory /home/inkrepo/experimental/src
used as include directory in directory
/home/inkrepo/experimental/src/2geom
used as include directory in directory
/home/inkrepo/experimental/src/libavoid
used as include directory in directory
/home/inkrepo/experimental/src/libcola
used as include directory in directory
/home/inkrepo/experimental/src/libcroco
used as include directory in directory
/home/inkrepo/experimental/src/libgdl
used as include directory in directory
/home/inkrepo/experimental/src/libuemf
used as include directory in directory
/home/inkrepo/experimental/src/libvpsc
used as include directory in directory
/home/inkrepo/experimental/src/livarot
used as include directory in directory
/home/inkrepo/experimental/src/libnrtype
used as include directory in directory
/home/inkrepo/experimental/src/libdepixelize
-- Configuring incomplete, errors occurred!
See also "/home/inkrepo/experimental/CMakeFiles/CMakeOutput.log".
See also "/home/inkrepo/experimental/CMakeFiles/CMakeError.log".
Just to prove CMake wrong about OpenMP and ImageMagick, I then did this:
liam@...3128...:/home/inkrepo/experimental$ cd ..
liam@...3128...:/home/inkrepo$ cat > openmp-test.cpp
#include <omp.h>
#include <stdio.h>
int main() {
#pragma omp parallel
printf("Hello from thread %d, nthreads %d\n", omp_get_thread_num(),
omp_get_num_threads());
}^D
liam@...3128...:/home/inkrepo$ g++ -fopenmp openmp-test.cpp -o a.out
liam@...3128...:/home/inkrepo$ ./a.out
Hello from thread 3, nthreads 4
Hello from thread 0, nthreads 4
Hello from thread 2, nthreads 4
Hello from thread 1, nthreads 4
liam@...3128...:/home/inkrepo$ ls /usr/include/GraphicsMagick
magick Magick++ Magick++.h wand
liam@...3128...:/home/inkrepo$ ls /usr/include/magick
analyze.h blob.h color_lookup.h common.h confirm_access.h
deprecate.h enhance.h gem.h list.h magick.h monitor.h
pixel_cache.h quantize.h resize.h statistics.h transform.h
api.h cdl.h colormap.h compare.h constitute.h describe.h
error.h gradient.h log.h magick_types.h montage.h pixel_iterator.h
random.h resource.h symbols.h type.h
attribute.h channel.h colorspace.h composite.h decorate.h draw.h
forward.h hclut.h magic.h memory.h operator.h plasma.h registry.h
shear.h texture.h utility.h
average.h color.h command.h compress.h delegate.h effect.h
fx.h image.h magick_config.h module.h paint.h profile.h render.h
signature.h timer.h version.h
What I'm not getting here is why CMake requires libmagickcore-dev to be
installed — on the same system, with the same installed packages,
./configure with no parameters passed says this:
Use gnome-vfs: yes
Use openoffice files: yes
Use relocation support: no
Enable LittleCms: yes
Enable DBUS: no
Enable Poppler-Cairo: yes
ImageMagick Magick++: yes
Libwpg: yes
Libvisio: yes
Libcdr: no
Doing Local Install: no
After installing libmagickcore-dev, I ran CMake again and it "worked". I
then ran make -k (and got the expected errors with poppler), but then this
error about missing Magick.h.
[ 20%] Building CXX object
src/CMakeFiles/inkscape.dir/extension/internal/bitmap/blur.cpp.o
/home/inkrepo/experimental/src/extension/internal/bitmap/blur.cpp:13:10:
fatal error: 'Magick++.h' file not found
#include <Magick++.h>
^
1 error generated.
*TL;DR *how do we get CMake to properly recognize OpenMP support, recognize
the correct Magick, and supply the correct headers?
8 years, 12 months
GSoC blurb for website
by Bryce Harrington
Now that GSoC is under way, it would be nice to replace the blurb on our
homepage with a list of what projects are under way (with links to
status if possible?)
Bryce
8 years, 12 months
Tile View widget
by Tomasz Boczkowski
Hi!
I'd like to share the first screenshots of the tile view widget. It
displays data in form of rectangular tiles divided into categories. It will
be used in pattern selection dialogs, swatches, glyphs and symbols. The
pictures are attached to this e-mail.
Code is available at lp:~penginsbacon/+junk/tile-view/
Regards,
Tomasz
8 years, 12 months
Frost for 0.91
by Bryce Harrington
The release process is ready to now move to the Frost phase.
1. Open development.
√ Triage and prioritize bugs report this year
√ Itemize regression bugs found since last release
2. Chill. √ Development focuses on wrapping up
√ Disable features that aren't finished
√ Identify 'make distcheck' issues
√ Identify any critical OSX/Win32 packaging issues
√ Identify remaining writing needed for Release Notes.
√ Regressions Bug Hunt: 500 points
√ Update tutorials and other docs
3. Frost. √ Experimental Branch is forked
√ Mainline Branch focuses on stabilization
√ Only production-ready code committed to Mainline
Post inkscape-0.91-pre0.tar.gz
Finalize any major changes to platform packaging
Release Notes should be >90% filled in.
Inkscape must pass >90% of 'make distcheck'
Start an About Screen contest
General Bug Hunt: 1500 points
Post additional inkscape-0.91-pre*.tar.gz releases
Packagers test creating pkgs of the -pre* releases
Mainline Branch
===============
During the Frost period, developers should not commit changes to
mainline unless the change improves the overall stability of Inkscape
or is needed for packaging or to fix distcheck issues.
Use your judgment as to what is "safe". If you're unsure, email me or
Josh before committing and we'll make case-by-case decisions. As a
general rule of thumb, if your commit doesn't specify a LP bug #, then
it should probably be signed off on by josh or I.
Experimental Branch
===================
The Experimental Branch is now forked. You can check it out via:
bzr branch lp:inkscape/experimental
This is an official (but temporary) branch, for freely merging all
development work. Please treat it as you would mainline when we're not
in release, and strive to keep it buildable and usable.
In particular, all merges of GSoC branches and other sponsored
development work should target this experimental branch instead of
mainline.
Bug reports will be accepted for the experimental branch. These bug
reports will be EOL'd when the experimental branch goes EOL.
About Screen Contest
====================
Josh, can you and Ryan work on organizing this? This contest will need
to be completed before we enter Freeze.
Make Distcheck
==============
Last I checked we had some distcheck issues, which will need to be
resolved before we release. Basically just run `make distcheck`
and work on sorting out the errors and warnings that print out.
Bug Hunt
========
This time around, any bug filed against Inkscape is fair game. I'll be
posting stats on Mondays. This next Monday I'll explain this in more
detail. I'll start the count as of May 5th.
Packaging
=========
If you are working on packaging improvements, please continue to do so,
with the goal of having it all in working order by the time Frost is over
(probably several weeks from now).
Bryce
8 years, 12 months
SPPattern class refactorization.
by Tomasz Boczkowski
Hi!
Tavmjonh Bah has suggested me to contact you and consult SPPaintServer
class refactoring I would like to do.
Currently SPPaintServer contains pattern_new method. Since it directly
handles rendering and uses cairo, I think it could be moved outside of SP
tree.
My idea is to implement paint server drawing routines in a parallel
hierarchy of classes belonging to New Renderer. Image [1] contains the
class diagram. Common base for them would be NRPaintServer, containing pure
virtual method pattern_new. Concrete NRPaintServer derivatives would
contain a reference to corresponding SPTree items and use it while
rendering.
To choose an appropriate NRPaintServer for given SPPaintServer I thought
about a factory method in NRPaintServer class. Example interfaces and their
usage are shown at [2]
The tricky part can be the implementation of NRPaintServer::create method.
I have thought about two solutions:
a) using a battery of dynamic_cast if statements like this:
NRPaintServer* NRPaintServer::create(SPPaintServer* ps) {
SPPattern* pattern = dynamic_cast<SPPattern*>ps;
if (pattern != 0) {
return new NRPattern(&pattern);
}
//and so on for gradients
}
b) using double-dispatch strategy. There would be an .cpp file internal
class NRPaintServerFactory.
class NRPaintServerFactory {
public:
virtual NRPaintServer* create(SPPaintServer*);
virtual NRPaintServer* create(SPLinearGradient*);
virtual NRPaintServer* create(SPRadialGradient*);
//and so on
}
And NRPaintServer::create implementation would look like this:
NRPaintServer* NRPaintServer::create(SPPaintServer* ps) {
static NRPaintServerFactory *factory = new NRPaintServerFactory;
return factory->create(ps);
}
What are your thoughts about this solution?
[1]https://www.dropbox.com/s/bz83xd0ks378qys/NRPaintServer.svg
[2]http://pastebin.com/h9AcrusW
Regards,
Tomasz
8 years, 12 months
Making inkscape usable in valgrind grumble
by mathog
Hi all,
In order to find memory leaks, some types of access violations, and the
use of uninitialized variables I depend on valgrind. The problem is
that valgrind is barely usable with Inkscape. The output on even the
most minimal session (open, type a few letters, format them, close) runs
to just under 500K lines and takes 5 minutes to complete. Some of this
may be because garbage collection must be turned off in order to use
valgrind. That is:
export _INKSCAPE_GC=disable;
valgrind .... src/inkscape
There is no choice in that though, because if it is not done valgrind
crashes when it tries to run inkscape. (Ubuntu 12.10.4, 32 bit, current
Trunk). There is a libgc.supp in the top of the distribution, but it
cannot be used on my system, since it does not suppress valgrind's crash
when it tries to run inkscape with GC enabled.
Here is the damage seen on a normal exit for a minimal run:
==16527== LEAK SUMMARY:
==16527== definitely lost: 567,697 bytes in 17,670 blocks
==16527== indirectly lost: 2,167,402 bytes in 73,234 blocks
==16527== possibly lost: 21,940,610 bytes in 282,461 blocks
==16527== still reachable: 21,470,100 bytes in 360,304 blocks
What can be done so that Inkscape makes a better effort at cleaning up
its enormous memory tangle when it exits while running in valgrind?
Some of the memory Inksape allocates is cleaned up, but it seems like a
very high percentage of memory allocations are tacked into this complex
memory structure, and inside valgrind the whole ball of yarn is just
dropped on the floor when the program reaches the final exit(), rather
than being unwound in an orderly fashion. (In theory GC may be
cleaning this up better, but I'm not sure how we can really know, since
valgrind cannot tell us.)
Could somebody who understands these parts of Inkscape PLEASE clean up
this mess, so that in future when "_INKSCAPE_GC==disable" Inkscape will
unwind its memory structures before exiting? At the very least we will
learn after this unwinding what memory is still left, and that will be
the result of existing bugs in the code. Once we obtain a baseline
inkscape that is usable once again in valgrind, we can reasonably expect
that by using valgrind developers will be able to catch the memory
problems they may introduce. Sadly that is far from true now, what with
so many thousands of lines of background noise in the log files to slog
through.
Admittedly some of the lines in valgrind's log file do come from
valgrind issues, but the ones I know about can be removed with:
cat >wcslen_sse2.supp <<EOD
{
wcslen1
Memcheck:Addr8
fun:__wcslen_sse2
fun:*
}
{
wcslen2
Memcheck:Cond
fun:__wcslen_sse2
fun:*
}
{
iffyinflate
Memcheck:Cond
fun:inflateReset2
fun:inflateInit2_
obj:*
}
EOD
valgrind -v --leak-check=yes --leak-resolution=high --num-callers=15
--show-reachable=yes --suppressions=./wcslen_sse2.supp
--log-file=/tmp/vgfi.log src/inkscape
which improves the output to:
--16527-- used_suppression: 208319 wcslen1
--16527-- used_suppression: 142 wcslen2
--16527-- used_suppression: 330 iffyinflate
==16527==
==16527== ERROR SUMMARY: 97190 errors from 13437 contexts (suppressed:
208791 from 656)
I understand that there may be other problems in some libraries which
are called, but from the contents of the log file it looks like the
majority of the loose ends were directly created in Inkscape. (And we
can use valgrind suppression files, as above, to silence the unfixable
library problems.)
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
8 years, 12 months
Win64: feature complete
by Johan Engelen
Hi all,
A quick note to let you know that aspell is now added to devlibs64,
so that the 64bit version of Inkscape on Windows is now feature complete
(i.e. same features as 32bit version)
Jay!
Johan
8 years, 12 months
Method to duplicate a SPDocument?
by mathog
If there is an existing method for making a copy of an SPDocument, what
is it called?
Resolving bug 1318657, without introducing other problems, seems to
require that the clipboard be replicated, and all actions occur on the
replica, which is then thrown away. See comments 8 and 9
https://bugs.launchpad.net/inkscape/+bug/1318657
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years
Removal of -inkscape-font-specification ?
by Tavmjong Bah
Hi,
I would like to propose the removal of the Inkscape specific
-inkscape-font-specification property. This property was added in 2007
in an attempt to allow Inkscape to handle more font faces for a given
font family than allowed by CSS.[1] It relied on Pango being changed to
support this.
In the intervening seven years, Pango has not changed nor does it seem
likely it ever will. There doesn't appear to really be a need to expand
on what CSS does already (and any SVG files that would use such a
feature would not be viewable correctly in browsers). Inkscape (trunk)
already supports, for example, all nine font faces of DejaVu Sans.
Support for the font-variant features of CSS Fonts Module Level 3[2]
would allow access to variants within a single font file which seems to
satisfy the need that -inkscape-font-specification was meant to address.
Font factories already have moved to put variants inside a single font
file (vs. keeping them in separate files). See for example the bug (from
2004) about Adobe Caslon[3] with the long list of variants and the
current OTF files from Adobe where the Small Caps, Alternative, and
Swash variants are included in the regular files.[4]
At the moment, -inkscape-font-specification duplicates the information
already stored in other font related properties. There is a cost in this
duplication, not only in increased file size but also in code
maintenance. Keeping -inkscape-font-specification matching the other
font properties is a source of bugs. It is currently making proper
quoting of font-family names in font-fallback lists more difficult to
fix.
The actual changes needed to remove -inkscape-font-specification are
straightforward and effect a few lines in about seven or eight files. No
functionality would be lost as the property is completely redundant with
the other font related properties.
Tav
[1] https://bugs.launchpad.net/inkscape/+bug/169973
[2] http://www.w3.org/TR/css3-fonts/#font-variant-prop
[3] https://bugs.launchpad.net/inkscape/+bug/165521
[4] http://www.myfonts.com/fonts/adobe/caslon/buy.html
9 years
![1]https://www.dropbox.com/s/bz83xd0ks378qys/NRPaintServer.svg](http://1]https://www.dropbox.com/s/bz83xd0ks378qys/NRPaintServer.svg){kind=link}