Re: [RFC] tools out of pdfedit module?

[Michal H. <ms...@gm...>]

Any conclusion to this discussion?

On Mon, Sep 14, 2009 at 10:11:08AM +0200, Michal Hocko wrote:
> On Sun, Sep 13, 2009 at 06:04:16PM +0000, Jozef Misutka wrote:
> > > On Sun, Sep 13, 2009 at 11:21:44AM +0000, Jozef Misutka wrote:
> > >>> On Sat, Sep 12, 2009 at 02:09:04PM +0000, Jozef Misutka wrote:
> > >>>>> On Thu, Sep 10, 2009 at 06:32:14PM +0000, Jozef Misutka wrote:
> > >>>>>>> On Thu, Sep 10, 2009 at 03:40:19PM +0000, Jozef Misutka wrote:
> > >>> [...]
> > >>>>>>>>> I am thinking that, maybe, we should get tools out of the pdfedit source
> > >>>>>>>>> completely and create a separate module for it in our CVS. The rationale
> > >>>>>>>>> is that we want to show how to use our pdfedit-dev-core library but it
> > >>>>>>>>> is not used if the source is in src/tools - at least from building POV.
> > >>>>>>>>> If we make it a separate module we can use proper Makefile
> > >>>>>>>>> infrastructure required for proper building and linking with the
> > >>>>>>>>> library.
> > >>>>>>>>>
> > >>>>>>>>> Just an idea... What do you think?
> [...]
> > > It looks like you are mixing two things. pdfedit-core-dev refers to the
> > > _external_ library! Something you have installed on your system and you
> > > can easily build programs up on. Source for it is a part of PDFedit
> > > project. There is no reason why GUI/tests should build against an
> > 
> > It does not make sense for our unit tests to use a library externally;
> > i hope that is clear.
> 
> Sure, it is project internall stuff.
> 
> > 
> > > external library if it is available directly.
> > 
> > Well, when tools have the library available too why should they not
> > link against it then?
> 
> Because we want to make this an _example_ on how to use the library.
> >From my POV this means 2 things: proper code usage and proper Makefile
> to build the code.
> 
> > 
> > See below.
> > 
> > >
> > >> This is definitely not correct except for the testing purposes.
> > >>
> > >> Currently we have these small projects in our main module:
> > >> - kernel - library
> > >> - GUI - should use the library, should be also an example of how to use ti
> > >
> > > I don't agree. PDFedit = GUI for manipulating PDF documents.
> > 
> > you clearly distinguish between gui and tools and
> > think of pdfedit as GUI for manipulating pdf. I started to think of
> > pdfedit as the library itself. GUI is only using the library. There is
> > where we do not agree. 
> > 
> > """
> > PDFedit = GUI for manipulating PDF documents.
> > """
> 
> > is 6 years old description, we should move forward. 
> 
> I think that we should stick with this description. 99% of user will
> never use the library and the only thing they will see is the GUI.
> Just look at the simple fact that the library was announced back in
> December and there is still no package for it in any Linux distribution
> I know of.
> 
> Making GUI out of pdfedit module simply doesn't make any sense to me.
> 
> > There is clearly application for the library so, imho, we should not
> > make differences between GUI and other usages.
> 
> Yes we should make a difference, because we distribute GUI! We are not
> distributing (except of Windows) tools for example.
> 
> > >> - tools - should use the library, should be also an example of how to use ti
> > >> - tests - directly test kernel library
> > >>
> > >
> > >> When I look at it now, if we want to separate something we have to
> > >> separate GUI as well! I am for this solution, but not for the partial
> > >> one separating only tools.
> > >
> > > This doesn't make sense. As I have already written above PDFedit = GUI
> > > not kernel. 
> > > The fact that we have made the core functionality as library
> > > which can be extracted doesn't make any change to the original
> > > intention of our project.
> > >
> > > Tools on other hand, is something which doesn't have anything to do with
> > > original project intention. It is a simple example how to use the core
> > > library.
> > 
> > See above why we disagree. Maybe we should reconsider the original
> > intention of our project? 
> 
> Reconsider to what?
> 
> > 
> > For example the original intention was for *nix users which are now a
> > minor user group! (see stats of downloaded files, more than 70% are
> > windows users)
> 
> Sorry, but this is flawed argumentation. As you already written in the
> other email sf.net statistics are download count only. This doesn't say
> anything neither about usage nor about linux distribution users who form
> the vast majority of PDFedit users (just check our support mailing list
> posts - almost nobody compiles sources from CVS or download tarball). 
> 
> > >> However, i have to mention one thing. From my experience, many
> > >> projects are very difficult to use because useful parts are all over
> > >> the place and you need to build/install 5 things before you get the
> > >> result.
> > >
> > >> Here, we will have one unusable part by itself (pdfedit-core-dev) and
> > >> other useful things somewhere else. IMHO, this si less user frienly
> > >> for most of our users!
> > >
> > > Sorry, I am not following you. What do you consider unusable about
> > > pdfedit-core-dev? Have you ever tried to deploy and use it? (I mean as a
> > > standalone system library)
> > 
> 
> > serious misunderstanding, i 100% support your idea to make
> > pdfedit-core-dev! i was talking about a normal user who wants
> > applications not libraries.
> 
> He has pdfedit and possibility to run scripts for all we have in tools
> currently (even though scripting usage sucks a bit - but this should be
> different in the new version of GUI).
> 
> > """
> > unusable part by itself
> > """
> > you install it and it cannot do anything by itself (cannot be run).
> 
> That is what libraries usually do ;)
> 
> [...]
> > >>> I think that nobody would like to select only important parts to get
> > >>> what he needs for a simple pdfedit-core-dev tool. Moreover when you
> > >>> check our README you will find out that making a proper Makefile for
> > >>> tools is really simple. But who reads README? I think almost nobody,
> > >>> so making it clear in tools and provide something to copy&paste is
> > >>> much better.
> > >>
> > >> This argument is silly, if we cannot be sure that ppl do not read
> > >> README then we cannot be sure that somebody will read API
> > >> documentation etc.
> > >
> > > Yes and face it, nobody does that. You have to serve everything if you
> > > want people to use/understand...
> > 
> 
> > You have to draw a reasonable line how to be user friendly. If
> > something is good it does not need to give everybody everything, it
> > only makes more mess.
> 
> Sorry, I am loosing context. We were talking about how to use
> pdfedit-core-dev and that clear README description is not enough because
> almost nobody reads such documents and I was arguing that this is the
> reason why tools should be put externally with Makefiles prepared for
> pdfedit-core-dev (external library).
> 
> > >>>> if not then something is wrong with our Makefiles.
> > >>>
> > >>> Could you be more specific? What is wrong?
> > >>
> > >> from previous email """ for g++ it should be easy using Makefiles from
> > >> tools directory, shouldn't it? if not then something is wrong with our
> > >> Makefiles. """
> > >>
> > >> If it cannot be reused easily something is wrong with them. Can they
> > >> be reused easily?
> > >
> > > Sorry, still not clear to me. What is wrong. What do you mean by reused
> > > easily? Have you looked at our makefile infrastructure and its
> > > connection to the configure? Please go through it and come back with
> > > specific arguments which we can deal with.
> > >
> > > I don't want to repeat myself, but look at what is necessary for
> > > pdfedit-core-dev application to build and than compare what would be
> > > necessary to extract from the PDFedit Makefiles...
> > 
> 
> > Michal, try looking at our *nix building schema from user point of
> > view, not from internal developer. I have something i want to reuse,
> > if i cannot reuse it easily it is not very good. 
> 
> Makefile and configure are *project* specific files. Each project is
> unique and has specific requirements. Therefore reusability term in this
> context doesn't make too much sense to me. Of course you can copy some
> parts and use it in a different project (e.g. proper boost or doxygen
> detection) or you can reuse scheme of Makefile.rules/Makefile.flags for
> clear project-wide build configuration but this is nothing I would call
> reusability.
> 
> > That is what i was trying to say all the time. I forgot the internal
> > structure of our Makefiles (and i really do not want to learn it
> > again) 
> 
> Please make familiar with something you are discussing about.
> 
> > but if it cannot be reused, it is probably not so well. (Imho,
> > i think it can be reused easily but you try to push your arguments :)
> 
> Have you ever looked at the Linux kernel building system? I consider it
> one of the best. But I don't thing that you can easily (or in some
> reasonable time) extract only some parts (e.g. scheme for modules
> building) out of it and reuse in a different project. 
> 
> > >>>> regarding (auto)configure it is up to the developers to extract
> > >>>> important parts from our scripts because they will probably use
> > >>>> other dependencies. maybe we can add a simple description to the
> > >>>> scripts themselves.
> > >>>
> > >>> This shouldn't be necessary. Check the pdfedit-core-dev-config
> > >>> script which sets proper compilation and linking flags. It is
> > >>> provided by pdfedit-core-dev library. If you install this library
> > >>> you have a guarantee that everything matches your system and you
> > >>> don't have to play with configure.
> > >>
> > >> A developer has to specify libraries which are necessary. I think that
> > >> ppl using our library for meaningful things will need also other
> > >> libraries so they have to be able to change the scripts anyway!
> > >
> > > Which libraries you have in mind?
> > > pdfedit-core-dev-config --libs returns all libraries for
> > > pdfedit-core-dev linkage.
> > 
> 
> > Developer is creating a new project, hmmm, he decides to use pdfedit
> > library and after that? the developer will probably also use other
> > libraries (for GUI for example) so he has to change the configure
> > scripts. do you understand now what i wanted to say?
> 
> Yes and what I am saying all the time is that he doesn't need to bother
> with our building system to accomplish that. All he needs to do is:
> 
> Check for pdfedit-core-dev-config script (if it doesn't exist then he
> needs to install the pdfedit-core-dev library). If it exists then he
> needs:
> PDFEDIT_CLFAGS = $(shell pdfedit-core-dev-config --cflags)
> PDFEDIT_LDFLAGS = $(shell pdfedit-core-dev-config --libs)
> CFLAGS = $(PROJECT_CFLAGS) $(PDFEDIT_CLFAGS)
> LDFLAGS = $(PROJECT_LDFLAGS) $(PDFEDIT_LDFLAGS)
> 
> See? This is explained in our README file all I would like to have is
> that tools would use the same scheme.
> The pdfedit-core-dev detection can be covered by a simple configure
> script (I can prepare one).
> 
> > 
> > I will summarize my views on the 2 main approaches:
> > 1. not separate
> > - evertyhing is in one place, more developer friendly, more user more friendly
> > - clear examples of usage GUI, tools
> > - step-by-step for ppl who wants to create their own applications
> 
> Except for a simple example how to build their own projects (read as no
> Makefile skeleton). 
> 
> > 
> > 2. separate 
> > - less user friendly, he needs to do more things to get e.g. GUI compiled
> 
> You are still discussing about GUI which I don't want to put out of the
> way exactly for this reason.
> If you put tools out of the main project you don't have to care about
> anything else but tools which you are interested in. Why would you want
> to download whole sources (testing documents, tests, GUI, kernel,
> documentation...)? See?
> 
> > - clear examples of usage GUI, tools - the same as in 1) according to my suggestion
> > - ""probably"" more reusable *nix Makefiles
> 
> Why probably. If you have a Makefile (skeleton one mentioned above) you
> can use it as it is.
> 
> -- 
> Michal Hocko
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Pdfedit-devel mailing list
> Pdf...@li...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-devel

-- 
Michal Hocko