Re: RFS: hnswlib
Hi Nilesh,
On 06.09.20 22:39, Nilesh Patra wrote:
> Hi,
>
> On Sun, 6 Sep 2020 at 18:32, Steffen Möller <steffen_moeller@gmx.de
> <mailto:steffen_moeller@gmx.de>> wrote:
>
> so I was a bit creative and
> added/removed symlinks to ../debian. This seems to do the job. If
> anyone
> out there knows how to do this properly - much appreciated.
>
>
> Wow, I must admit, that workaround looks very cool!
> I pushed in a couple minor changes please `$git pull` and let me know
> if they look OK :-)
You have done so much good stuff all around Debian Med already, I trust
you and leave the rest to the sponsor, typically this is Andreas. For
everything else we then have "git blame" *=|;O)
>
> I also had a couple of doubts which I'd want to ask regarding the
> d/rules file (I am not very aware of all dh_* operations):
>
> 1. What is being done in the section: "|override_dh_builddeb|" here[1]?
You should have seen me swearing prior to that change. :) dh_builddep is
called from within the "python_bindings" subdirectory, so the .debs are
created in the source tree instead of in "..". So I pass the destination
dir as a parameter, depending on the directory it is executed in.
> |2. In line 16[2] the buildsystem is being changed according to the
> "@" variable - would you mind explaining as to how this variable
> changes at different stages of the build?|
> |($@ is treated as a target in classic Makefile but I've got no idea
> about it's association with debhelper and consequent build steps)
> |
|This dates back from the very origins of how d/rules files were created
prior to the advent of debhelper. There was a build target (which
invoked build-arch and build-indep) and install and binary as targets.
This dh magic basically now has a Makefile rule for each of the tools
that traditionally contributes to the package production. And it grouped
a few bits together that you can override together, like "dh_auto_clean"
or "dh_auto_build". But this is more like an internal organisation, not
the target that dpkg-buildpackage would request. When I don't want to
start a build from the beginning (everything cleaned by
dpkg-buildpackage), I typically run "fakeroot ./debian/rules binary",
i.e. d/rules is treated like an executable that initiated /usr/bin/make
that you have in the shebang line. |
|The motivation for that $@ inspection was that I want the build and the
install all done within the subdirectory with all the "--with python3"
magic of debhelper. Once that is all built and installed the rest should
be done from the root of the source tree. What kind of helped is that
this is a header-only library, so other than the Python work that went
into the python3-hnswlib package there was no extra work than to read
the debian/libhnswlib-dev.install file. But this finishing of the
binaries should be done from the root of the source tree, so I asked if
"binary" was the target that is being worked on and then did not enter
the subdir. But it feels like I was cheating, so ... I happily accept
corrections.
|
|Best,|
|Steffen|
Reply to: