C++ support in User Modules

[elliotwoods]

Hey

I understand that Micropython itself is written in C and not C++
However, a user might want to develop a micropython module which calls to a C++ library or is written in C++ code.

Currently, this is very difficult, as the Makefile system currently does not support C++, and is itself very a complicated Makefile system (especially for an outsider).

I presume that it's not necessary to change the micropython C code at all, but just to change the Makefiles.

The repository https://github.com/stinos/micropython-wrap is interesting. But this currently does not support microcontrollers, so I've added an issue at stinos/micropython-wrap#5 there also

Thank you
Elliot

[elliotwoods]

So far these edits seem to work (testing only a very simple cpp file with one class definition)
elliotwoods@73afcd8

Notably you now also have SRC_USERMOD_CPP += lines in your micropython.mk
These files are compiled, but not sent to the QSTR cache parser (i.e. they are not added to SRC_QSTR)

Testing now with trying to get Tensorflow to build..

[elliotwoods]

I got tensorflow CPP library working here in a really hacky way

1. Add CPP files to py/py.mk elliotwoods@73afcd8#diff-8cb873f8d91be202cc15633f10a62f49
2. Add CPP->O files to esp32/Makefile elliotwoods@73afcd8#diff-77cbec69bd2e6d723afa755b9d99031b
3. Rename any .cc files to .cpp
4. Manually build all the .cpp files into the right places with a separate script https://github.com/elliotwoods/micropython/blob/elliot-modules/ports/esp32/auto_build_tensorflow.sh

This obviously isn't a scalable way to build modules with CPP in the future, but helps outlines perhaps the missing steps within the current Makefile system.

[Ecco]

For the record, it's already possible and works very well. You can look at this repo for a few examples. And you probably can write an extension in any compilable language actually, you just need a tiny bit of C code for interop.

I think this issue should be closed 😄

[elliotwoods]

@Ecco - Great to hear it should already be working
Thank you for the response

A few notes as to why this issue might not be closed just yet.

• The folders that you linked to contain cpp code, but do not contain micropython.mk files. i.e. they don't work like standard micropython extensions. How do they work? It seems that the project uses its own Makefile system, and this issue is related to the Makefile system within this repo
• Adding a line like SRC_USERMOD += $(USERMODULES_DIR)/Model.cpp to micropython.mk results in an error like xtensa-esp32-elf-ld: cannot find build-GENERIC/../../modules/tensorflow/Model.cpp: No such file or directory (i.e. there is no build rule for cpp files)
• Members of the MicroPython community say that cpp build system is not implemented right now : https://forum.micropython.org/viewtopic.php?f=3&t=7353

It's possible that compatibility with cpp files varies between hardware platforms. I'm not sure which hardware the Epsilon (which looks really cool btw) has been tested on.

The more I looked into fixing this issue myself, I feel like it's a really easy fix for somebody who knows the Micropython Makefile system (I ended up making a simple bash script to build the cpp files manually)

[stinos]

Note: the ESP32 Makefile already has a rule for building C++ files. I'd suggest to start with moving that to mkrules.mk already: it doesn't hurt, I think, plus it makes the amount of changes required to add C++ files to the build smaller in general. I.e. add

define compile_cxx
$(ECHO) "CXX $<"
$(Q)$(CXX) $(CXXFLAGS) -c -MD -o $@ $<
@# The following fixes the dependency file.
@# See http://make.paulandlesley.org/autodep.html for details.
@# Regex adjusted from the above to play better with Windows paths, etc.
@$(CP) $(@:.o=.d) $(@:.o=.P); \
  $(SED) -e 's/#.*//' -e 's/^.*:  *//' -e 's/ *\\$$//' \
      -e '/^$$/ d' -e 's/$$/ :/' < $(@:.o=.d) >> $(@:.o=.P); \
  $(RM) -f $(@:.o=.d)
endef

vpath %.cpp . $(TOP) $(USER_C_MODULES)
$(BUILD)/%.o: %.cpp
	$(call compile_cxx)

to mkrules.mk since it already has the same for C files.

[stinos]

@dpgeorge this can be closed now