On 23 February 2018 at 08:31, zyx <z...@gmx.us> wrote:
> you should discuss such invasive changes before suggesting them and
> sending them to the list. Your changes in public headers are wrong.
> Maybe they make things easier for static library usage, but they break
> dynamic library usage.

You're right, but I felt confident since this kind of change it's
usually safe. Relative paths should be looked up first by the notation
#include "../header.h", so at the moment I don't know exactly what is
wrong with dynamic library usage or #include <podofo/podofo.h>

> I agree with that and I've been thinking of it some time ago too. Some
> projects just rename the 'src' with the expected directory name (in
> this case 'podofo'), which avoids one directory level in the sources,
> but having 'src/podofo/...' is also fine by me.

'src/podofo' also have the advantage that it totally eliminates the
pollution of including podofo source "root" directory. The cons is
that it adds another directory level of course, but I think the pros
of eliminating the need of wrappers is way bigger. What to do now? Do
you endorse me anyway in modifying headers to use relative paths
(provided I fix them to work in the other use cases) or you prefer not?
If not, will you consider modifying the source layout to "root/src/podofo"
in the short or middle term?

> One unrelated comment to this issue, but being related to your
> submissions: when you said you are going to send git-formatted patches,
> then I expected patch attachments, not emails with patches in their
> body. I know git can do it, but you see that what had been received on
> the list is just a plain mess.

I'm sorry: patch reviewing with inline patches is the rule in other
notable projects, but I'm guest here and I will follow the "house
rule" and do attachments. In other comment: did you consider to move
to a more collaborative platform like github for source management? In
this way easy patches can be sent by pull requests, and mailing list
can still be used for more invasive changes discussions.

> I also do not like tons of small patches when they are supposed to fix
> one issue (the sources should be buildable after each commit, which
> adds some burden to the thing), but I agree that it's sometimes better
> to split it. I mean, while some of your changes are fine to be in
> parts, I'd merge some into one a-bit-larger patch. Just my opinion.

I splitted patches in 3 series actually:
1) Series "[0/13] Miscellaneous fixes and improvements", were supposed
to be easily mergeable changes;
2) Series "[0/3] Improvements to annotations appearance API". It's a
more relevant API addition. My fault it depends on TryGetMethod
present in series (1).
3) Series "[0/1] More flexibility when using PoDoFo as a static
library": the series we are discussing here.

I added cover letters to identify them but I understand more series
streamed one after another caused mess. Just for this time, will you
consider reviewing series (1) and (2) individual patches for inclusion?
If not, please tell me how to procede.


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Podofo-users mailing list

Reply via email to