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> notation. > 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. Regards, Francesco ------------------------------------------------------------------------------ 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 Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
