[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[MoM]: libquazip



Hi Andreas,

I took the liberty to start a new thread for th MoM libquazip.

2012/6/4 Andreas Tille <andreas@an3as.eu>:
> On Mon, Jun 04, 2012 at 05:51:13PM +0200, Eric MAEKER wrote:
>> We have two "natural" ways to build the source and create the package:
>> - the upstream natural way is to add some params to the qmake command line (what I've done). This way three simple commands are needed (qmake, make, make install). Using a simple patch, I can even try to build release and debug libs in one command.
>
> I'd prefer the non-patchy way because it is more easy to maintain.  If I
> understand correctly when using qmake instead of say automake the qmake
> takes over the role of configure, right?  This seems to perfectly fit
> the fact that you have overriden dh_auto_configure - so this is fine.

Yop the qmake creates all the Makefile using
- the command line params
- a qmake.conf
- a spec file
I think it is acting like a

    ./configure

command.

> I'm perfectly new to qmake - so I'm also a bit guessing what might be
> the proper way to go.  However, after doing some reasearch about dh and
> qmake I think the best way to go would be:
>
>   dh $@ --buildsystem=qmake
>
> Would you like to test this to possibly profit from other automatic
> adjustments (like perhaps hardening flags etc which might be set that
> way - I have not tried, just speculating).

Ah ok. I toke some time to read some debian files (libqxt for eg) that
uses this config. The debian/rules is then very clear and short !
I'll read some doc about this and will make some tries.

>> - the d-shlibs way which seems to be natural in the Debian packaging world. I can not find any documentation about d-shlibs with google. May be you can send me some links ?
>>
>> As I am not a Debian guru, I will follow you choice (my preference is to use qmake).
>
> This is definitely a total missunderstanding of the role d-shlibs is
> playing.  It comes *after* the make install step so it is no replacement
> for qmake at all.  After you did a make install $(CURDIR)/debian/tmp
> d-shlibs takes over and verifies that files will end up in the right
> location and that debian/control contains the proper names and
> Dependency relations.

Not enough geek to understand the script without a good documentation.
Do you have one ?
For the moment, I'll try to improve the building system:
- use the --buildsystem=qmake
- build the debug lib
- build a multi-arch package (I'm actually reading some docs)

>> Ok, give it a test and let me know. I did not work on symbol versioning as I did not understand anything to this matter...
>
> So d-shlibs is definitely for you because *it* understands this matter
> and is checking for you that everything is fine.  (Guess why I'm using
> it. ;-))
>
>> I've adapted the freemedforms code to take into account the availability of the libquazip package. Using the qmake command you can define if you want or not to use the packaged lib (in this case, libquazip is not built by freemedforms otherwise it is). Then I tested the lib with freemedforms and did not experiment any problem (I have just to check that my freemedforms build used the headers of the packaged libquazip).
>
> Hmmm, did the package build at your site as it was commited.  IMHO SVN
> commits r11202 and r11204 are definitely needed to build the package at
> all.  I can not imagine that you was able to build it without these
> changes.  Understanding r11202 is specifically important to understand
> Debian packaging.  (Please tell me if it remains unclear to you.)

Does we have a very simple interface for the svn log/diff (something
like http://code.google.com/p/freemedforms/source/list) ?

> Moreover the doc package is empty.  I made a very stupid typo when
> injecting it.  Do you see the problem?  That's your training task -
> seeking for such bugs is a good training (and no I do not make such
> errors intentionally and took me also some time to see what's wrong).

Read for the challenge, I'll check out tomorrow (@work now).

>> Ah ah ah... Good... We are exactly "on the same radiowave" :) Yesterday I started to write you a private mail to ask you about updating the svn path to libquazip as well as the source package name.
>
> Hups, do not remember, but fine if it is that way.

I did not send it cause of an internet connection break...

>> I've done the change.
>
> Good.
>
>> > name the source package (in changelog and control) from quazip
>> > to libquazip.
>>
>> done too.
>
> Only have done -> r11202.

Eric


Reply to: