PlatformIO Community

Building libraries in PlatformIO - something I'm missing


#1

Hi there,

I’m using PlatformIO to try to create a LORAWan application for an ESP based board ( using Arduino framework ). There are a few problems, so I want to turn debug on for the relevant LORA library. This seems to involve changing one #define in the library code, via an arcane mechanism that causes the relevant #define to be redefined. Whatever, when I make the relevant change I obviously need to rebuild the library.

PlatformIO has downloaded all the sources for the library, but what I’m missing is how I’m supposed to trigger PlatformIO to do the rebuild ? I don’t see a makefile/cmake file with the library, but there’s a ‘travis’ thing that looks like it might be a build description. But I thought travis was used only via github. And indeed, PlatformIO appears to make no attempt to rebuild the library simply as a result of me altering the #define, which is only what I expected. I have absolutely no desire or intention to put my change to this library anywhere near github, it’s just a local hack to turn debug on.

So I’m stuck. How do I get PlatformIO to rebuild this thing ?

Thanks,
Mark


#2

If the compiler doesn’t detect a change to the file which needs it to be rebuilt, you can do a ‘clean’ to remove all the compiled binaries. The travis file is a template for continuous integration (i.e. if you have an automated build setup that triggers when you commit code).

image

If you are defining a flag in say main.cpp, there may be no need for it to rebuild the library anyway, only the main.cpp that was changed.

i.e. if you consider the following

testing.h

#ifndef TESTING_H
#define TESTING_H

#ifdef DEBUG 
#warning "Testing was here!"
#endif

#endif

main.cpp

#define DEBUG 

#include <Arduino.h>
#include <testing.h>

void setup() {
  // put your setup code here, to run once:
}

void loop() {
  // put your main code here, to run repeatedly:
}

Commenting/uncommenting #define DEBUG will turn on and off the output from testing.h, but only the binary for main.cpp needs to be rebuilt.

Compiling .pioenvs/uno/src/main.cpp.o
In file included from src/main.cpp:4:0:
lib/testing/testing.h:5:2: warning: #warning "Testing was here!" [-Wcpp]
#warning "Testing was here!"

#3

Hi Peter, thanks for getting back to me, it looks like doing a clean has indeed forced a rebuild of the relevant library, thankyou.

But now I’m going to try to understand a bit more about PlatformIO :).

Obviously PlatformIO has to build any library it downloads ( i.e. it’s not downloading prebuilt libraries ), because it needs to target the specific hardware/platform/framework combination that the project is using. My LORA library is a global library ( I may have a whole bunch of projects that use it ), but I assume the object/library output lives in the project.

But where is it getting the rules from for doing this, if they are not provided with the library ? Does it just rely on having default behaviour ( or a set of default behaviours, depending on target ) for a given type of source file and a given hardware/platform ? So it does not actually have ( or build ) a dependency network of any sort, other than the default dependency between source type and object ? That would expain why changing a header could not force a rebuild ( which is what I would expect to happen in an environment that did maintain dependencies ). Would it still behave like this if a makefile, or some other form of dependency description, was supplied ?

Cheers,
Mark


#4

Excellent. In regards to your further question on the compile process… I can’t really answer that from any position of knowledge… I honestly don’t know how the compiler (probably gcc) makes the decisions as to whether a file needs to be rebuilt or not. I would presume that when it is compiled to binary form, that the decision tree (#ifdef, etc) is still present in the binary, so that if other code needs to use that path it is available, and if it’s not used, it is stripped out if it can be as part of optimisation.

This could be an interesting read (for both of us! :slight_smile: ) :
https://www3.ntu.edu.sg/home/ehchua/programming/cpp/gcc_make.html