0

I've used Buildroot quite a bit over the years, and I've always managed to find solutions to the obstacles I've hit. But this one has me going in circles.

I've added a git-sourced python tool as a host package to my Buildroot build for an ARM target. I have completed the work on the package/Config.in.host and the package/toolname/Config.in.host as well as package/toolname/toolname.mk files. Everything looks to be in order. I have compared the work with what the add_new_package.wizard outputs.

The new option DOES appear in the menuconfig.

It is NOT available as a make target, although I do have target-side packages I have included that ARE valid make targets. i.e. I can run: make target-side-package-name and those packages are built just fine.

I cannot run: make host-side-package-name as I get the error "No rule to make target".

So there must be something I'm doing incorrectly with the host package, although I clearly am doing the right things with the target packages.

Everything points to Buildroot simply ignoring my host package, other than sticking it into the menuconfig. My hours of searching on the webs have led to not one single post about someone having this same problem. I'm missing something obvious I would think.

My question is - what debugging can I do, where can I look to find out what is keeping Buildroot from properly recognizing my new package?

EDIT: I believe I understand now that part of the problem is the build order, and perhaps I can fix one issue with dependency directives. My target package that relies on the host package was being built first. I had assumed as common sense would dictate that host packages would be dealt with first, but that is apparently not true.

EDIT: Posting the .mk file 

TOOLNAME_VERSION = 2
TOOLNAME_SITE =  $(call github,devname,toolname,$(TOOLNAME_VERSION))
TOOLNAME_SETUP_TYPE = setuptools  
TOOLNAME_LICENSE = GPL-3.0  
TOOLNAME_LICENSE_FILES = LICENSE  

HOST_TOOLNAME_DEPENDENCIES = host-python-library  

$(eval $(host-python-package))  

TOOLNAME = $(HOST_DIR)/usr/bin/toolname

As I hinted before, it is now running just fine so I know it's mostly set up correctly, the remaining problem is the make target is missing. Per the Buildroot manual, I should have one available.

I have now discovered that the missing make target is in fact making it impossible to build other packages dependent upon this one. The build of the dependent package now fails because "No rule to make" on the toolname package it is made to depend upon through TARGET_PACKAGE_DEPENDENCIES = toolname

T S
  • 93
  • 8
  • The mailing list and IRC channel are the best places for such questions. You'll find better replies there. Also your question is quite vague: can you provide your Config.in and .mk files (maybe obfuscating sensitive data)? – Luca Ceresoli Oct 17 '17 at 07:24
  • Thanks for the suggestion. I've posted the .mk, there's really nothing of interest in the Config.in.host it's simple and the package shows up in menuconfig and is built correctly. It's just the make target problem that's flustering me now. – T S Oct 17 '17 at 18:10

2 Answers2

1

Can you post your toolname.mk? It sounds like you forgot to add the $(eval $(host-python-package)) line.

Peter Korsgaard
  • 626
  • 4
  • 3
0

Hallelujah! The answer is that the make target name is NOT toolname, but is instead host-toolname. The root cause of the problem is the lack of mention of this nuance in section 8.12.5 of the Buildroot documentation. I stumbled across the answer while researching package dependencies in Chapter 17, where it does identify proper use for that specific case.

T S
  • 93
  • 8