The desctiption for compiling in the wiki seems to describe compiling the older monolythical homegear and not the new modular version.
I tried to guess how to compile but failed.
What I did was:
download and extract Homegear, lib-homegear-base, Homegear-HomeMaticBidCoS and Homegear-HomeMaticBidCoS
confugre, make, make install of lib-homegear-base
confugre, make of lib-homegear-base Homegear-HomeMaticBidCoS whicht then fails
Question 1:
What is the right order to compile and install the modules?
Question 2:
How do the modules find references to their other parts? Is it sufficient to install the different parts or do I need to tell configure the path to them?
You need one package from the Homegear repository: libphp7-homegear. That is probably the reason for your compilation error. Just install it using “apt-get” after adding the Homegear repository.
Only if you want to compile Homegear by yourself: libphp7-homegear
libhomegear-base (required by all other parts)
Homegear
Modules
It is sufficient to install libphp7-homegear and libhomegear-base. The make script puts all necessary files into directories where the other parts can find them.
Now, I needed to regenerate the “configure” Scripts with aclocal && autoheader && automake --add-missing && autoconf (in each of the module directories) as “install-sh” was not found.
Now I do:
cd libhomegear-base
./configure
make
sudo make install
cd ../Homegear
./configure
make
cd ../Homegear-HomaticBidCoS
./configure
make
which fails because of the include directive
Did you manage to compile it now? I replaced all “../homegear-base” now, too. That was the old directory. I didn’t notice, because for some reason compilation works here…
Yes. And it’s up and running, but only because I disconnected the connection between CC1101 and GPIO during start up.
I left config (all under /etc/homegear/) and DB like it was from my previous Homegear installation with apt-get (and replaced the homegear binary and the modules).
Now during startup I get:
11/09/15 21:59:53.336 Error: Failed to export GPIO with index 2 for device "cc1100": GPIO not defined in physicel devices' settings.
11/09/15 21:59:53.336 Error: Failed to export GPIO with index 2 for device "cc1100": GPIO not defined in physicel devices' settings.
11/09/15 21:59:53.338 Error: Could not setup GPIO for device cc1100: GPIO path for index 2 is not set.
11/09/15 21:59:53.338 Error: Could not setup GPIO for device cc1100: GPIO path for index 2 is not set.
11/09/15 21:59:53.339 Failed to set direction for GPIO with index "2": GPIO not defined in physicel devices' settings.
11/09/15 21:59:53.339 Failed to set direction for GPIO with index "2": GPIO not defined in physicel devices' settings.
Has the format of the config files (especially physicalinterfaces.conf) changed?
I am using the Pollin module with this configuration:
#######################################
########## TI CC1101 Module ##########
#######################################
# The device family this interface is for
[HomeMaticBidCoS]
# Specify an unique id here to identify this device in Homegear
id = My-CC1101
# When default is set to "true" Homegear will assign this device
# to new peers.
default = true
# Options: cul, cc1100, coc, cuno, hmcfglan, hmlgw
deviceType = cc1100
device = /dev/spidev0.0
## Default: responseDelay = 95
## Should be "95" for CUL or COC, "100" for TI CC1101 and "60" for HM-CFG-LAN or HM-LGW
responseDelay = 100
## The interrupt pin to use. "0" for GDO0 or "2" for GDO2.
## You only need to connect one of them. Specify the GPIO
## you connected the interrupt pin to below.
interruptPin = 0
## The GPIO GDO0 or GDO2 is connected to. Specify which GDO to use above.
gpio1 = 18
my mistake. I indeed changed the physicalinterfaces.conf, because we added support for the TI CC1190. I will fix that tomorrow. For the time being set “gpio2 = ANY_FREE_GPIO” and “txPowerSetting = 0xC2”. That should work.
adding the 2 lines to physicalinterfaces.conf made the errors disappear. Thank you!
However, the version I compiled does not fix my initial problem (activating interrupt pin after disabling the 135kHz Signal on GDO0).
More on this issue (soon) on the original thread here.
BUT you should rethink which generated artifacts of the autoconf toolchain you submit to the repository.
As already written, the configure scripts didn’t word out-of-the-box (i.e. out of the github repo), so I needed to regenerate them (aclocal && autoheader && automake --add-missing && autoconf).
This results in that I cannot pull from your Github repo because the changes that took place on the source tree (either by the autoconf/automake stuff or by gcc dependency generation):
Updating 9e73df0..700b4b0
error: Your local changes to the following files would be overwritten by merge:
Makefile
config.h
config.status
configure
homegear-miscellaneous/src/.deps/Factory.Plo
homegear-miscellaneous/src/.deps/GD.Plo
homegear-miscellaneous/src/.deps/MiscDevice.Plo
homegear-miscellaneous/src/.deps/MiscPeer.Plo
homegear-miscellaneous/src/.deps/Miscellaneous.Plo
homegear-miscellaneous/src/LogicalDevices/.deps/MiscCentral.Plo
homegear-miscellaneous/src/Makefile
homegear-miscellaneous/src/Makefile.in
libtool
src/.deps/main.Po
src/CLI/.deps/CLIClient.Po
src/CLI/.deps/CLIServer.Po
src/Database/.deps/SQLite3.Po
src/Events/.deps/EventHandler.Po
src/GD/.deps/GD.Po
src/MQTT/.deps/Mqtt.Po
src/MQTT/.deps/MqttSettings.Po
src/Makefile
src/Makefile.in
src/RPC/.deps/Auth.Po
src/RPC/.deps/Client.Po
src/RPC/.deps/ClientSettings.Po
src/RPC/.deps/RPCMethod.Po
src/RPC/.deps/RPCMethods.Po
src/RPC/.deps/RPCServer.Po
src/RPC/.deps/RemoteRpcServer.Po
src/RPC/.deps/RpcClient.Po
src/RPC/.deps/Server.Po
src/RPC/.deps/Webserver.Po
src/ScriptEngine/.deps/libscriptengine_a-PhpEvents.Po
src/ScriptEngine/.deps/libscriptengine_a-PhpVariableConverter.Po
src/ScriptEngine/.deps/libscriptengine_a-ScriptEngine.Po
src/ScriptEngine/.deps/libscriptengine_a-php_sapi.Po
src/Systems/.deps/DatabaseController.Po
src/Systems/.deps/FamilyController.Po
src/Systems/.deps/PhysicalInterfaces.Po
src/UPnP/.deps/UPnP.Po
src/User/.deps/User.Po
Please, commit your changes or stash them before you can merge.
Aborting
Unfortunately I cannot provide you good knowledge of autoconf/automake (there may be better build tools available today, like cmake), but I think it is common among open source projects that you supply a configure script that runs without missing local files (like install-sh) and there are no generated artifacts like dependencies generated by gcc, Makefiles generated by configure script etc. in the repository’s source tree.
As far as I understand the “autotools philosophy” the autogen.sh or bootstrap script should prepare everything to enable someone who uses the source distribution to run the configure script.
thanks for reading into this ! I will change the name from autogen.sh to bootstrap then , remove the configure and won’t use autoreconf.
Cheers,
Sathya
Edit: For the time being I will keep autogen.sh AND bootstrap until I recreated the Docker build images. When the new images are online I will remove autogen.sh.