[Pkg-pascal-devel] Bug#823706: lazarus opengl

[Paul Gevers]

Hi Abou,

On 11-11-16 22:49, Abou Al Montacir wrote:
> I agree with the goal (test delivered stuff), and agree with the tool
> (lazbuild). I'm not sure I understand your statement about lazbuild is
> not the right tool.

Well, that was my conclusion from this e-mail conversation and the fact
that it doesn't work in the location where we ship the files. Nothing
more. So I'll trust your analysis that it is the right tool.

> If a package builds using lazbuild, then it will
> build using IDE. The opposite is also true, if it does not build using
> lazbuild it will not build using IDE. Of course the the issue is that
> you don't have any way to let lazbuild chenge output dir except the sed
> on lpk or cp -Rfpl of /usr/lib/lazarys. The latest one is my preferred.

Just to be clear, if I just cp the (sub) dir than compiling with
lazbuild still mimics the way the IDE builds? And the IDE build is smart
enough to put the files in the right location where lazbuild doesn't?
Why do most *.lpk create their files in $HOME/.lazarus/ while some (or
some type of files) don't get created there.

My "problem" with copying the files is that we can already test that
during the build process (add a autotest target to d/rules and have that
run at the end of the build) and that I explicitly want to test AS
SHIPPED, i.e. like what the user would see. But if the IDE is smarter
than lazbuild, it seems we can't.

At least you can see the results
https://ci.debian.net/packages/l/lazarus/
Looks like I forgot to add the lazarus build depends to the depends of
the test.

>> So, it looks like I can check most (but not all) *.lpk packages with
>> lazbuild. As the IDE seems to be doing stuff differently, I can't test
>> that properly.
> I think I need more clarification of above statement.

Maybe you can check the debian/tests/build-lpk-lpi file. Everything that
I filter out, I can't build on the system location. The rest works. At
the bottom, I summarized each error that happens and a single line
remark about my current understanding if any.

>> Interesting note: the lazarus source ships multiple *.lpk files that
>> can't be build using only the lazarus source as the dependencies are NOT
>> in the tar ball. What do you think, should we not ship these *.lpk files
>> as they are useless without the proper source? E.g. lazarus doesn't have
>> the source for something called bgrabitmappack:
> That we can ask upstream to explain how do they expect to get sources of
> missing packages. It may just be a bug in packaging.

Could you do that please. Until know I feel reluctant to ask these kind
of questions as my "Debian" questions were treated slightly hostile
upstream (my "simple" bug reports were treated OK, so it is just that I
feel uncomfortable with distribution related communication).

> Seems a third party project:
> https://github.com/bgrabitmap/lazpaint/tree/master/bgrabitmap
> there youc an find
> https://github.com/bgrabitmap/lazpaint/blob/master/bgrabitmap/bgrabitmappack.lpk
> and
> https://github.com/bgrabitmap/lazpaint/blob/master/bgrabitmap/bgrabitmappack.pas
> 
> I hope this helps

I found the above as well, but I am not really interested in pulling in
third party stuff (unless it is packaged in Debian), not even to test.

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20161112/ddf5228e/attachment.sig>