u-blox / ubxlib

Portable C libraries which provide APIs to build applications with u-blox products and services. Delivered as add-on to existing microcontroller and RTOS SDKs.
Apache License 2.0
287 stars 82 forks source link

Compiling & building #250

Closed danzadok closed 1 week ago

danzadok commented 3 weeks ago

Is there any instructions document or script how to build? I am trying to build for Windows. Do you have any MS Solution/Project file to share? It seems that modules are using internal header files of other modules. For instance the internal header files in the folder port\platform\common\debug_utils\src are used by other modules. Is there any INCLUDE convention for compiling and building? Where can I find the list of the compilation directives like U_CFG_DISABLE_TEST_AUTOMATION, that should be configured?

RobMeades commented 3 weeks ago

Hi there, and thanks for posting. We provide build instructions for the runner application which executes all of our tests and examples, the Windows version can be found here. You will see that for Windows we provide CMake files that can be imported into VSCode. Of course, ultimately you don't want to build our runner application, you want to build your own application, but this should show you how things are put together and then you can adapt that to your own needs.

It seems that modules are using internal header files of other modules.

Our naming convention for header files can be found here, but you shouldn't need to worry about any of that; as far as the application is concerned just #include <ubxlib.h> and you will get all of the public header files, the ones in the api directories; an application should not need to refer to header files in a src (or test) directory.

Where can I find the list of the compilation directives like U_CFG_DISABLE_TEST_AUTOMATION, that should be configured?

You should not need to define anything: that kind of stuff is only used internally when we are testing. From an application perspective, with a very small number of exceptions (geofencing and cellular PPP), we deliberately avoid use of compilation flags. Now if you are building our examples then you will see that the examples files do include macros, things like U_CFG_TEST_CELL_MODULE_TYPE and U_CFG_APP_PIN_CELL_TXD etc.; these are documented in the README.md for each set of examples (e.g. see here for the sockets one), but this is just to make the examples easy to build, none of those values are built into ubxlib itself, in your application you can just put a number, ubxlib does not care.

RobMeades commented 1 week ago

@danzadok: is it OK to close this now?

danzadok commented 1 week ago

Yes , Thanks

On Tue, Jun 25, 2024 at 5:49 PM Rob Meades @.***> wrote:

@danzadok https://github.com/danzadok: is it OK to close this now?

— Reply to this email directly, view it on GitHub https://github.com/u-blox/ubxlib/issues/250#issuecomment-2189169363, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGC4W323MYNEV4WDT63LHRLZJF7PDAVCNFSM6AAAAABJDRLK2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBZGE3DSMZWGM . You are receiving this because you were mentioned.Message ID: @.***>

-- :) Danny Zadok

danzadok commented 1 week ago

Thanks

On Tue, Jun 11, 2024 at 12:29 PM Rob Meades @.***> wrote:

Hi there, and thanks for posting. We provide build instructions for the runner application which executes all of our tests and examples, the Windows version can be found here https://github.com/u-blox/ubxlib/blob/master/port/platform/windows/mcu/win32/README.md. You will see that for Windows we provide CMake files that can be imported into VSCode. Of course, ultimately you don't want to build our runner application, you want to build your own application, but this should show you how things are put things together and then you can adapt https://github.com/u-blox/ubxlib/blob/master/README.md#examples that to your own needs.

It seems that modules are using internal header files of other modules.

Our naming convention for header files can be found here https://github.com/u-blox/ubxlib/blob/master/DEVELOPMENT_PRINCIPLES.md#be-careful-what-you-expose, but you shouldn't need to worry about any of that; as far as the application is concerned just #include and you will get all of the public header files, the ones in the api directories; an application should not need to refer to header files in a src (or test) directory.

Where can I find the list of the compilation directives like U_CFG_DISABLE_TEST_AUTOMATION, that should be configured?

You should not need to define anything: that kind of stuff is only used internally when we are testing. From an application perspective, with a very small number of exceptions (geofencing https://github.com/u-blox/ubxlib/blob/master/common/geofence/README.md and cellular PPP https://github.com/u-blox/ubxlib/blob/master/cell/README.md#ppp-level-integration-with-a-platform), we deliberately avoid use of compilation flags https://github.com/u-blox/ubxlib/blob/master/DEVELOPMENT_PRINCIPLES.md#avoid-compile-time-dependencies-within-ubxlib. Now if you are building our examples then you will see that the examples files do include macros, things like U_CFG_TEST_CELL_MODULE_TYPE and U_CFG_APP_PIN_CELL_TXD etc.; these are documented in the README.md for each set of examples (e.g. see here https://github.com/u-blox/ubxlib/tree/master/example/sockets for the sockets one), but this is just to make the examples easy to build, none of those values are built into ubxlib itself, in your application you can just put a number, ubxlib does not care.

— Reply to this email directly, view it on GitHub https://github.com/u-blox/ubxlib/issues/250#issuecomment-2160242493, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGC4W36FQV6GLO6RWY4ZXOTZG27QHAVCNFSM6AAAAABJDRLK2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRQGI2DENBZGM . You are receiving this because you authored the thread.Message ID: @.***>

-- :) Danny Zadok