- Inkscape Devel - Inkscape Mailman

make doing unneeded compilations?
by mathog 22 Mar '14

22 Mar '14

Lately I have noticed that when I come back to Inkscape on another day, modify a single cpp (today's was drawing-text.cpp) and "make" it starts rebuilding all sorts of things that would seem to be utterly unrelated. In fact, the build is so extensive it may well be a complete rebuild. Here is just a fraction of the things it compiled: ... CXX sp-mesh-gradient.o CXX sp-mesh-patch.o CXX sp-mesh-row.o CXX sp-object.o CXX sp-path.o CXX sp-pattern.o CXX sp-rect.o CXX sp-shape.o CXX sp-stop.o CXX sp-style-elem.o CXX sp-text.o CXX sp-tref.o CXX sp-tspan.o CXX sp-use.o CXX style.o ... If the same file is later modified again, "make" the next time does the expected thing and just compiles that one file and then links everything. Any idea why it is doing that? It almost seems like the Make files now have some concept of "old" object files and anything over a day old gets rebuilt. Trunk 13168, Ubuntu 12.04.4 LTS Configure was run with export CPPFLAGS="-DWITH_SVG2" ./configure --disable-strict-build Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

4 6

libuemf: upmf.c
by Johan Engelen 22 Mar '14

22 Mar '14

Hi David, In libuemf/upmf.c, what is this line of code supposed to do? line 3096: U_SERIAL_DESC *List = List; Thanks for fixing, Johan

1 0

filter2D_IIR problem
by Johan Engelen 22 Mar '14

22 Mar '14

Hi all, There may be a bug in nr-filter-gaussian.cpp. The following warning is emitted: src/display/nr-filter-gaussian.cpp: In function 'void Inkscape::Filters::filter2D_IIR(PT*, int, int, const PT*, int, int, int, int, const IIRValue*, const double*, IIRValue* const*, int) [with PT = unsigned char, unsigned int PC = 1u, bool PREMULTIPLIED_ALPHA = false, IIRValue = double]': src/display/nr-filter-gaussian.cpp:504:45: instantiated from here src/display/nr-filter-gaussian.cpp:342:13: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] src/display/nr-filter-gaussian.cpp:343:13: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] src/display/nr-filter-gaussian.cpp:504:45: instantiated from here src/display/nr-filter-gaussian.cpp:358:17: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] The warning is emitted because the (incredibly ugly!) #define PREMUL_ALPHA_LOOP for(unsigned int c=0; c<PC-1; ++c) will resolve to #define PREMUL_ALPHA_LOOP for(unsigned int c=0; c<0; ++c) for the template instantiated value for PC = 1. Meaning that the loop will never run. Is this intended? If so, please fix the code to not emit that warning. If it's a bug, please fix the bug! :) Thanks, Johan

2 1

Re: [Inkscape-devel] Warning on explicit cast in libuemf
by Johan Engelen 21 Mar '14

21 Mar '14

Back to on-list. On 21-3-2014 20:07, mathog wrote: > > 1. Why do we need libiconv in devlibs at all since it is already in > mingw? It is not in my copy of MinGW (TDM-GCC). > 2. Why is the version in devlibs 1.09 (from 2003 or 2004) when 1.14 > is current (and the version in mingw)? Don't know. How harmless is upgrading without upgrading our other dependencies? ciao, Johan

1 0

Warning on explicit cast in libuemf
by Johan Engelen 21 Mar '14

21 Mar '14

Hello David, in libuemf/uemf_utf.c, there is /** \cond */ /* iconv() has a funny cast on some older systems, on most recent ones it is just char **. This tries to work around the issue. If you build this on another funky system this code may need to be modified, or define ICONV_CAST on the compile line(but it may be tricky). */ #ifdef SOL8 #define ICONV_CAST (const char **) #endif //SOL8 #if !defined(ICONV_CAST) #define ICONV_CAST (char **) #endif //ICONV_CAST /** \endcond */ An example of the macro usage: ... status = iconv(conv, ICONV_CAST &src, &srclen, &dst, &dstlen); ... This generates a warning because, at least on Windows, iconv expects a (const char **) and gcc complains about an unsafe cast. This is not at all trivial, and is a very valid compiler warning. Please read this: http://stackoverflow.com/questions/14562845/why-does-passing-char-as-const-… I do not know how to fix this at the moment. Of course I could do an #ifdef for Windows to replace the cast with what iconv wants, but.... Thanks for having a look, Johan

3 3

Incomplete switch statement
by Johan Engelen 21 Mar '14

21 Mar '14

Hi all, Yesterday I changed the compiler flags to now error on incomplete switch statements (-Werror=switch). Because of this, a buildbot found a tiny bug with GTK3: CXX ui/dialog/input.o ../../src/ui/dialog/input.cpp: In member function 'bool Inkscape::UI::Dialog::InputDialogImpl::eventSnoop(GdkEvent*)': ../../src/ui/dialog/input.cpp:1917:16: error: enumeration value 'GDK_SOURCE_KEYBOARD' not handled in switch [-Werror=switch] ../../src/ui/dialog/input.cpp:1917:16: error: enumeration value 'GDK_SOURCE_TOUCHSCREEN' not handled in switch [-Werror=switch] ../../src/ui/dialog/input.cpp:1917:16: error: enumeration value 'GDK_SOURCE_TOUCHPAD' not handled in switch [-Werror=switch] First: jay! for buildbots! The actual error is not too bad, just needs someone to look over the new GDK_SOURCE_s and figure out how to handle them there, with an #ifdef for GTK3. Jon, can you have a look? Thanks for fixing this, Johan

1 0

CSS Merging Bug
by Martin Owens 21 Mar '14

21 Mar '14

Hi Devs, I need some help with the style bug #167937 I've created this patch which I've put into a branch which fixes the direct issue as it does not corrupt element styles with css values any more: http://bazaar.launchpad.net/~doctormo/inkscape/css-style/revision/13177 It's a fairly simple patch which redirects the stylesheet setter so it sets the computed value of each of the properties instead of the actual value. But it has bugs. Elements appear black until they have been nudged, then the style is applied. I can imagine the parent/inherited styles probably suffer the same bug but it's been under reported. I'd also be interested in hearing if this is the right approach to fix the bug. Would it be better to change it so it updated the styles value but kept the .set set to false to indicate no real value should be saved? Thanks for your help, Best Regards, Martin Owens [1] https://bugs.launchpad.net/inkscape/+bug/167937

2 2

Warnings: compiler flags
by Johan Engelen 20 Mar '14

20 Mar '14

Hi all, Can someone tell me where to add compiler warning/error flags for Makefile users? (On Windows, I know) Am going to slowly activate erroring on specific warnings. Thanks, Johan

3 4

Re: [Inkscape-devel] Warning on explicit cast in libuemf
by mathog 20 Mar '14

20 Mar '14

On 20-Mar-2014 16:10, Jon Cruz wrote: > > The more "big picture" solution is to just get rid of uemf_utf.c > altogether. ... > So a rough idea would be to delete uemf_utf.c and uemf_utc.h and > replace the conversion use in other files with the standard Glibmm > calls. libUEMF has no glib dependencies. It happens that when libUEMF is used in Inkscape glib is available, but that is not the case in other situations. Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Status of Inkscape 0.91 Release
by Bryce Harrington 20 Mar '14

20 Mar '14

2. Chill. DONE Development focuses on wrapping up DONE Disable features that aren't finished Identify 'make distcheck' issues Identify any critical OSX/Win32 packaging issues Identify remaining writing needed for Release Notes. DONE Regressions Bug Hunt: 500 points Update tutorials and other docs Can you help me identify where we are with the remaining items in the above list? 1. I ran 'make distcheck' and hit an error: CXX event-log.o ../../src/event-log.cpp:11:33: fatal error: util/signal-blocker.h: No such file or directory compilation terminated. There were also a bunch of errors in libcroco, that'll all need cleaned up. 2. I have zero insights into OSX or Win32 packaging. Can someone give me a low-down on what the current state is with these? Do we have all the dependency changes covered? Do the packaging scripts still work and produce a viable binary? Any other issues folks are worried about? (I do not want to find ourselves blocked from releasing due to Win32/OSX packaging problems, so if there are any I want to get them on the radar now, so we don't move forward from chill or freeze until they're sufficiently taken care of.) 3. I reviewed the ReleaseNotes a few months back and they looked really solid. Are there any areas you see where we need more attention? 4. Which features from this release need to have documentation and/or tutorials made? Is there any other tutorial or documentation work that will require tracking with the release? Bryce

12 29