- Inkscape Devel - Inkscape Mailman

Building with make
by Isobel Knowles 26 Mar '14

26 Mar '14

Dear Chaps, After much testing with different configurations on a couple of platforms, I think my Makefile is ready for you to try. As I said earlier, I have completely failed to get launchpad to work on my browser so I have worked on the only released version I could get my hands on - 0.48.4. Should you feel it is worthwhile continuing with this approach I am happy to port it to 0.48.5 and beyond. The purpose of my changes is to simplify the configuration and build process, to improve automation, and to do so in an easily-maintainable fashion. I recognise that the autotools and automake in particular, although superficially easy, perform a lot of heavy scripting to produce Makefiles which are far too complicated for most users to read. This in turn makes many developers wary of making anything but the simplest of changes. As a first step toward breaking down this barrier I have removed the need for automake and placed the make rules in plain sight. Although I am still using autoconf to configure the code, the configuration is now cleanly separated from the build itself, and is now simple enough that it can be done by hand without autoconf at all. The changes amount to this: - A bit of tweaking of the configure script to remove automake. - The removal of the myriad of automake files. - The creation of a Makefile which does pretty much everything automake did, but without the mystery. - Adding some convenient structures to aid debugging. - A small number of code fixes to deal with glaring bugs made evident by the above & to clean up the version number storage. (These have probably been fixed already.) I have tried to contain my changes to just autoconf/make-related matters so as to reduce the impact on those later versions of Inkscape which are currently unavailable to me. To keep my changes small I placed all the make stuff in one file. I appreciate this might rankle, but I felt it was best to concentrate on the overall problem for now and sort out the detail later. Please bear this in mind when you review the changes. I have tested the software on Linux with different libraries and compilers. One of the systems was a bang up-to-date Debian Wheezy. Therefore I suggest a developer with a Linux system be the first person to work with me. I have also tested (insofar as I can) a cross compilation with a Linux build machine. I feel confident this should work too, but there are bound to be a variety of problems which will come out of the woodwork. Builds on Windows/Mac should work, but are untested. In the process I couldn't help but notice the cxxtests directory appears to have bitrotted. Is this true of later versions? I have not addressed binary packaging yet because the documents I have seen seem inexplicably complex to me. If someone could tell me how it is actually done on the various platforms I can automate them as well. Source packaging is done. I have documented my changes to the build process in INSTALL and in the Makefile itself but am happy to improve them at your suggestion. This is a work-in-progress. Assuming broad agreement, I would like to: - port it to an up-to-date version, - iron-out the platform issues, - address packaging and distribution, - fix and automate testing, - address linking, libraries and source file grouping, and - attack the many compilation warnings. in the next few weeks. Without further ado, please find two attachments to this email. I have provided it this way to keep it small. You should: - Extract 0.48.4 into a directory and change into it. - Extract the two attachments to this email into that directory. - rm `cat delete-list` - patch -p1 -E -i diffs - rm delete-list diffs - Read INSTALL and the other files it points to. - autoconf configure.ac > configure - Configure, make, install and prepare tar files like so: sh ./configure make -j 6 make install DESTDIR=foo make dist adjusting to your taste. Also try sh ./configure --help to see the new options. Regards, Is.

4 7

Possible problem in Geom::Path
by Markus Engel 25 Mar '14

25 Mar '14

Hi, In 2geom/path.cpp, ll 338-340, the following can be found: // this approach depends on std::vector's behavior WRT iterator stability get_curves().erase(first_replaced, last_replaced); get_curves().insert(first_replaced, first, last); get_curves() returns a std::vector&, all parameters are iterators. Both the comment and a failed debug assertion (Expression: vector insert iterator outside range) made me look this case up and I'm quite sure that this is not allowed: std::vector::erase Iterator validity Iterators, pointers and references pointing to position (or first) and beyond are invalidated [.]. http://www.cplusplus.com/reference/vector/vector/erase/ So (at least) first_replaced is invalid in the second line. Can anyone confirm this? Is there an easy workaround? Regards, Markus

2 2

setAttribute std::string or Glib::ustring
by Johan Engelen 25 Mar '14

25 Mar '14

Hi all, To easier use repr->setAttribute, I want to add two extra (overloaded) functions virtual void setAttribute(gchar const *key, gchar const *value, bool is_interactive=false)=0; virtual void setAttribute(gchar const *key, Glib::ustring const &value, bool is_interactive=false)=0; virtual void setAttribute(Glib::ustring const &key, Glib::ustring const &value, bool is_interactive=false)=0; Should I use std::string or Glib::ustring for this? Thanks, Johan

3 7

clang static analysis report
by Markus Engel 25 Mar '14

25 Mar '14

Hi, here's the results of running scan-build on a part of the sources. I interrupted it, this takes quite a while. Anyway, you've got 263 possible bugs to check. Either there are many false positives or. inkscape shouldn't even start :) . Open index.html: https://db.tt/3Nj4vpmG Regards, Markus

2 3

Re: [Inkscape-devel] clang static analysis report
by Johan Engelen 24 Mar '14

24 Mar '14

(back to list) On 24-3-2014 23:58, mathog wrote: > 4. I don't understand what it is warning about at line 706 in > upmf.c. It doesn't like this: > > int U_DPO_free(U_DPSEUDO_OBJ **dpo){ > if(!dpo){ return(0); } > if(!*dpo){ return(1); } > U_DPSEUDO_OBJ *kpo = *dpo; > if(kpo->poPoints){ U_PO_free(&kpo->poPoints); } > if(kpo->poTypes){ U_PO_free(&kpo->poTypes); } // <------ > free(*dpo); > *dpo=NULL; > return(1); > } > > At the arrow it gives the warning: "Branch condition evaluates to a > garbage value" > > The U_DPSEUDO_OBJ struct looks like this > > typedef struct { > uint32_t Elements; /**< Element count, applies to both > PseudoObjects */ > U_PSEUDO_OBJ *poPoints; /**< Points in path */ > U_PSEUDO_OBJ *poTypes; /**< Types of points in path */ > } U_DPSEUDO_OBJ; > > and this is U_PO_free() > > int U_PO_free(U_PSEUDO_OBJ **po){ > if(!po)return(0); > if(!*po)return(1); > if((*po)->Data)free((*po)->Data); > free(*po); > *po=NULL; > return(1); > } As you can read on the webpage that scan-build generates, there are 18 steps involved. The reason that line 706 is bugged is because for some control flow "kpo->poTypes" has a garbage value. The cause is that for the control flow indicated, the U_DPSEUDO_OBJ *Path is never fully properly initialized, in particular kpo->poTypes isn't. -Johan

1 0

Where is clipping information stored relative to an sp object?
by mathog 24 Mar '14

24 Mar '14

Along with implementing more of the EMF clipping records I'm looking into implementing clipping output to that format, which at present is completely unsupported. All the EMF output code sees is a pointer to "style", but it can get back from there to the object. Can one of you enlighten me as to the "path" from the object back to the stored clipping paths and the logic that ties them together? The data that needs to be extracted by working back up the data tree is like this: pathvector1 (a simple clippath with one path, references nothing else) done pathvector1 AND pathvector2 (a clippath that is itself clipped by another clippath) done pathvector1 OR pathvector2 (a clippath that has two paths) done Ideally this would be as C++ variables and not as the corresponding SVG text, so it would not need to be parsed again. Also on a related point, EMF clipping has modes that support AND, OR, XOR, and DIFF. EMF input goes through a text SVG intermediate, so the first two can be done using <clippath> syntax that I'm already aware of. Does SVG have path combination syntax for XOR and DIFF (subtract)? I know Inkscape has code that will operate on pathvectors to do this, but what I'm asking is if there is a standard SVG syntax that Inkscape supports more or less along these lines: <path> id="XORofPath1AndPath2" operator="XOR" path1="(a path specification)" path2="(another path specification)" </path> Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

2 1

libcroco fix
by Johan Engelen 24 Mar '14

24 Mar '14

To the maintainer of our libcroco copy, Please have a look at rev. 13178, where I fixed errors in pointer type signed-ness (Glib functions like g_strdup want a gchar*, not a guchar*). I guess you'd want to upstream the small change. cheers, Johan

5 7

Windows builds: enable -Werror
by Johan Engelen 23 Mar '14

23 Mar '14

Hi all devs on Windows, Please consider enabling -Werror for your work. I added stuff to build.xml to make it easy for you to see the status of trunk. Just remove the space between "-" and "->" to enable -Werror on line 356. Currently, there are 3 warnings/errors left (tdm-gcc 4.6.1). They are very likely to be false positives. But I am not sure yet. Make sure you don't add any new ones! Thanks for your effort in improving the code quality and stability of Inkscape. cheers, Johan

1 0

Possibly unitialized used of variable
by Johan Engelen 23 Mar '14

23 Mar '14

Hi all, GCC 4.6.1 gives an uninit var warning in sp-canvas.cpp: src/2geom/generic-interval.h: In static member function 'static void SPCanvasGroup::update(SPCanvasItem*, const Geom::Affine&, unsigned int)': src/2geom/generic-interval.h:144:8: error: '*((void*)(& bounds)+24).Geom::GenericInterval<double>::_b[1]' may be used uninitialized in this function [-Werror=uninitialized] src/display/sp-canvas.cpp:1051:19: note: '*((void*)(& bounds)+24).Geom::GenericInterval<double>::_b[1]' was declared here ... I have been working on this warning for hours, but I cannot find the problem. Because I have already found a (serious) bug from another warning like this, I am very reluctant to conclude that it is a compiler mis-analysis. I would greatly appreciate someone else having a (thorough) look at this. Thanks, Johan

5 10

I want to help and I want help……
by MARK BUCHALTER 23 Mar '14

23 Mar '14

To the developers. (GREAT PROGRAM) I am a web developer and created an app using mostly inkscape…that works well… but unfortunately, no mater how great a program this is,…... it is still a work in progress…. I am getting many bugs when try to revise and want to share what I have done and get some feedback. AND Try to help solve some of this issues. I would be happy to discuss this with anyone who thinks they can assist…please look at the App…located here….. http://www.digitaldudes.com/1-visualizer/9-link-visualizer.svg this is a swim suit / active ware designer I created…. I have not seen anyone else doing this kind of stuff… maybe because it is hard to make money BUT…PLEASE LOOK THANKYOU MARK BUCHALTER captbuck@...2857... cell" 340-642-3740

2 1