NFD

search for Boost libraries in the /usr/lib/arm-linux-gnueabihf directory (for armhf)

None of these folders should appear in the build script. Moreover, folders for x86 and amd64 should be removed. Instead, use dpkg-architecture -qDEB_HOST_MULTIARCH to determine the multiarch tuple.
https://github.com/named-data/ppa-packaging/issues/15#issuecomment-269842891

I don't think we should put distribution-specific commands inside the build script. For PPA scripts, it is ok, as they are for the specific Linux distribution type.

I don't think we should put distribution-specific commands inside the build script.

Is there any non-Debian-derived distribution that use a library directory with multiarch tupe?

I agree with Alex here. What happens if we run these commands on macOS? We might get weird values for the directory or there might (theoretically) be another program with the same name that produces different output.

What happens if we run these commands on macOS?

You should never run dpkg-architecture on a non-Debian-derived system, nor should you add a path like /usr/lib/tuple because this path is only on Debian.

there might (theoretically) be another program with the same name that produces different output

This shouldn't be a problem. Otherwise, same can be said for pkg-config and g++.

Junxiao Shi wrote:

What happens if we run these commands on macOS?

You should never run dpkg-architecture on a non-Debian-derived system, nor should you add a path like /usr/lib/tuple because this path is only on Debian.

I don't think we can say with 100% certainty that this path format for libraries is only used on Debian.

Then we also have the task of detecting the specific distribution of Linux we're running on from Python, which could prove to be difficult.

I don't think we can say with 100% certainty that this path format for libraries is only used on Debian.

As I asked on note-5, please give an example on a non-Debian-derived system using multiarch tuples.
Without a specific example, I'll be against adding any new tuples, but I won't object keeping the existing two tuples.

Then we also have the task of detecting the specific distribution of Linux we're running on from Python, which could prove to be difficult.

The existence of dpkg-architecture indicates Debian (see also note-7 second part). It is part of dpkg-dev package that is a dependency of build-essential package, so NFD won't gain a new dependency.

Junxiao Shi wrote:

Then we also have the task of detecting the specific distribution of Linux we're running on from Python, which could prove to be difficult.

The existence of dpkg-architecture indicates Debian (see also note-7 second part). It is part of dpkg-dev package that is a dependency of build-essential package, so NFD won't gain a new dependency.

Yes, but how do we easily check for the existence of dpkg-architecture from within Python?

Yes, but how do we easily check for the existence of dpkg-architecture from within Python?

That's actually not a big problem. This can be done as detecting any other program (like pkg-config) in waf.

I've submitted a pull request for this upstream (https://github.com/waf-project/waf/pull/2146).

I'll work on commits for the rest of the projects actively built on Jenkins soon.

Eric Newberry wrote:

We require >=2.6, so I'll modify all the changes to work on 2.6.

*We* actually require >= 2.7, and we already use check_output elsewhere, but it's better to use the same patch that upstream will eventually merge.

I don't care about python 2.6, it is dead. Python 2.7 is on life support also, but as long as our code works with it (with a few non-critical exception), I'm fine.

Davide Pesavento wrote:

Eric Newberry wrote:

We require >=2.6, so I'll modify all the changes to work on 2.6.

*We* actually require >= 2.7, and we already use check_output elsewhere, but it's better to use the same patch that upstream will eventually merge.

We should update the ndn-cxx INSTALL.rst then, because it says Python >= 2.6.

We should update the ndn-cxx INSTALL.rst then, because it says Python >= 2.6.

Sure.

Changes have been merged except for ndn-cxx (failed due to Jenkins issues) and projects that appear broken for other reasons (ChronoShare, ndn-atmos, and ndn-group-encrypt).

ndn-group-encrypt has been replaced with name-based-access-control, so I've pushed a change for that project (Alex abandoned the one for ndn-group-encrypt).