Skip to content

Add nanopb package#11157

Closed
Citrullin wants to merge 2 commits intoRIOT-OS:masterfrom
Citrullin:nanopb_package
Closed

Add nanopb package#11157
Citrullin wants to merge 2 commits intoRIOT-OS:masterfrom
Citrullin:nanopb_package

Conversation

@Citrullin
Copy link
Contributor

Contribution description

Add nanopb package. See example of how it works. Just create proto directory with your proto files. Include the package in your app:

USEPKG += nanopb

And that's it. The Makefile will do the rest for you. It compiles the header and c files for you.

Testing procedure

cd examples/nanopb_example && make

Copy link
Contributor

@jcarrano jcarrano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The processing of the proto files should be moved outside the package. Currently our handling of generated files is less than optimal, I ran into similar issues with the Lua package, and I'm still not satisfied with the results.

The package's makefile should be written so that it does nothing if it should do nothing.


# Todo: Not sure if that really works on Windows. Somebody should test it.
# Check if we are running on Windows
ifdef windir
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ifeq ($(strip $(OS)), Windows_NT)
  BLABLABLA
endif

rm -rf $(PROTO_BUILD_DIR) && \
mkdir $(PROTO_BUILD_DIR) && \
cp $(PKG_DIR)/Makefile.template $(PKG_BUILDDIR)/Makefile && \
$(MAKE) -e PROTO_BUILD_DIR="$(PROTO_BUILD_DIR)" -e PROTO_FILES="$(PROTO_FILES)" \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The processing of the .proto files should not be done by the package's makefile.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why shouldn't it? Otherwise the user has to take care of it or has to keep some code for it in the applications Makefile. I want to keep it as simple as possible for the user.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The package's makefile should only take care of building the package. The rest of the rules must be in Makefile.include so that they are added to the main makefile. It is possible to define it so that the user does not have to worry about anything: the same way it is done for .c files:

  • Use a wildcard to collect .proto files
  • From this collection, create a target for each .proto.
  • Define an implicit rule so that make knows how to build a pb.{c,h} from a .proto

@@ -0,0 +1 @@
INCLUDES += -L$(PKGDIRBASE)/nanopb/ -I$(PKGDIRBASE)/nanopb/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the place to include the Makefile.template so that the rules for processing proto files are executed by the top level make.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The processing of the proto files should be moved outside the package. Currently our handling of generated files is less than optimal, I ran into similar issues with the Lua package, and I'm still not satisfied with the results.

The package's makefile should be written so that it does nothing if it should do nothing.

Okay, I take a look into the Lua package. Thanks for the info. I just don't want to have this in the applications Makefile. The user shouldn't maintain this. Should just run out of the box after including the package into the project.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In lua I had to keep it there because the integration was a bit more tricky and because I could not get #9565 in. Your case should be easier, but if it isn't and we need to change stuff (read fix stuff) in the build system to make it work, we will.

endif
endif

$(PROTO_FILES):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typing make clean does not clean these files.

TOOLCHAIN_FILE = $(PKG_BUILDDIR)/xcompile-toolchain.cmake

PKG_DIR=$(CURDIR)
PROTO_DIR=$(APPDIR)/proto
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"compiled" .proto files should go under bin/. Unfortunately, there is currently no place to put "target-independent" files (like generated files) so they will have to go under bin/${BOARD}/proto_whatever.

all: $(PKG_BUILDDIR)/Makefile
cp $(PKG_BUILDDIR)/libnanopb.a $(BINDIR)/nanopb.a

$(PKG_BUILDDIR)/Makefile: $(TOOLCHAIN_FILE)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because this depends on $(TOOLCHAIN_FILE), which depends on git-download which is a PHONY target, this rules is being executed every time.

-e PROTO_DIR="$(PROTO_DIR)" -e PKG_BUILDDIR="$(PKG_BUILDDIR)" -C $(PKG_BUILDDIR) proto lib

$(TOOLCHAIN_FILE): git-download
$(RIOTTOOLS)/cmake/generate-xcompile-toolchain.sh > $(TOOLCHAIN_FILE)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because of the dependency on a phony target, this gets executed every time. Move this to all.

@PeterKietzmann PeterKietzmann added Type: new feature The issue requests / The PR implemements a new feature for RIOT Area: pkg Area: External package ports labels Mar 13, 2019
@kaspar030
Copy link
Contributor

@Citrullin we seem to be working on similar stuff... I had a branch with nanopb RIOT integration lying around. I wouldn't have PR'ed it after seeing this PR, but I think the integration in #11157 is somewhat cleaner.
Could you take a look?

@Citrullin
Copy link
Contributor Author

Citrullin commented May 23, 2019

@kaspar030 Wrong PR. It is #11157. Yes, I will take a look.

@Citrullin
Copy link
Contributor Author

Closed, due to merged implementation in #11565

@Citrullin Citrullin closed this Oct 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: pkg Area: External package ports Type: new feature The issue requests / The PR implemements a new feature for RIOT

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants