Issues when building a static library project in ModusToolbox

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
stan4233_475378
Moderator
Moderator
Moderator
25 replies posted 10 questions asked 50 sign-ins

Hello,

I have created a static library project (libhello-demo) to illustrate the issues I've encountered.  I wanted the project to generate libhello.a, which I can then linked with, in another project.  I'm using ModusToolbox 2.4 in Ubuntu 18.04.5 LTS (64 bit).

The static library has 1 public function:

bool test_me(void) {

    return true;

}

As the implementation does not use any BSP or SDK library, I would like the resultant .a to be usable across all PSoC 6 boards (e.g. PSoc6 Prototyping Kit and Pioneer Kit).

I have attached the steps to reproduce the issues (steps.zip).  Also, I have attached the project code (libhello-demo.zip), although you can also find it on Github (https://github.com/mtb04313/libhello-demo)

The project Makefile has defined LIBNAME=libhello.  Initially, I set TARGET=CY8CPROTO-062-4343W, so that I can perform make getlibs successfully in Step 1

Then make build in Step 2 fails. 

To workaround the failure, I temporarily comment out LIBNAME line, and added APPNAME=apphello instead (shown in Step 3).  Now, make getlibs downloaded a bunch of dependencies into mtb_shared (capsense, core-lib, core-make, mtb-hal-cat1, mtb-pdl-cat1, psoc6cm0p, recipe-make-cat1a).

Then in Step 4, I reverted to LIBNAME=libhello (commenting out APPNAME line).  This time, make build succeeded and produced libhello.a.

My questions are:

1. Why don't "make getlibs" and "make build" work with LIBNAME=libhello?  Why do I have to fake an APPNAME?

2. How can I avoid defining a TARGET, so that my static library does not require a bunch of unnecessary Capsense and BSP files during compilation, and so have the static library work with any PSoC 6 boards?

3. Can I make the resultant library usable for both M4 and M0 cores?

Thanks!

Best Regards,

SK

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.
stan4233_475378
Moderator
Moderator
Moderator
25 replies posted 10 questions asked 50 sign-ins

Hello Alen,

Currently with the default manifests, I'm able to pull Github dependencies, so I'm not sure how using custom manifest files will help. Are you suggesting I should make a custom TARGET?

I found a workaround for my problems and wanted to share the answers to the 3 questions.

1. to use LIBNAME=libhello, I first have to include in the deps sub-folder:

core-lib.mtb
core-make.mtb
mtb-pdl-cat1.mtb
psoc6cm0p.mtb
recipe-make-cat1a.mtb

I 'copied' these files from the libs sub-folder (from the APPNAME case).

2. I retained the TARGET definition in the Makefile, but added a .cyignore so as to avoid building unnecessary code.

# .cyignore
$(CY_GETLIBS_SHARED_PATH)$(CY_GETLIBS_SHARED_NAME)/TARGET_CY8CPROTO-062-4343W/
$(CY_GETLIBS_SHARED_PATH)$(CY_GETLIBS_SHARED_NAME)/mtb-pdl-cat1/
$(CY_GETLIBS_SHARED_PATH)$(CY_GETLIBS_SHARED_NAME)/psoc6cm0p/

3. the resultant .a does not have any BSP code and should be usable across all M4 projects (though I'm unsure about M0).

Building 2 file(s)
Compiling app file libhello_api.c
Compiling ext file world_api.c
Archiving output file libhello.a

I have updated libhello-demo (https://github.com/mtb04313/libhello-demo) and attached the steps (steps_optimized.zip).

Thanks!

Best Regards,
SK

View solution in original post

7 Replies
AlenAn14
Moderator
Moderator
Moderator
500 replies posted 100 solutions authored 250 replies posted

Hi @stan4233_475378 ,

Thank you for using our products.

I will try out the steps you have  mentioned and get back to you with my observations in a days time.
Thank you for your patience.

Regards
Alen

0 Likes
AlenAn14
Moderator
Moderator
Moderator
500 replies posted 100 solutions authored 250 replies posted

Hi @stan4233_475378 ,

1. Why don't "make getlibs" and "make build" work with LIBNAME=libhello?  Why do I have to fake an APPNAME?
A] In a normal project created in ModusToolbox, the make procedure follows that it requires a target to start the build operation which essentially includes dependency files that are retrieved by the command 'make getlibs'. Hence creating the static library on such a project will need the target dependencies since the TARGET field in Makefile is always necessary else the build will fail. If the target and its dependencies are not necessary then you can create the static library by following the method described below.

2&3 ] Please find the answer to your questions 2 and 3 below:

You can create a static library project in MTB by doing the following :
File -> New -> Project -> C/C++ -> C/C++ Project -> C Managed Build -> Static Library -> Empty Project

I named the project as 'mystaticLibrary' and here you can create/add your own .c and .h files without having to specify the TARGET device. (There is no make file involvement here). Once you have added your source files, build the same and a corresponding .a static library file will be generated in the folder 'Debug'. (The 'Debug' folder will only be observed after building)
You can now add this .a file in any of your desired project (no need to modify the make file, just copy paste the .a file to make file directory of desired project) and use the functions in the same. 

AlenAn14_0-1638264434672.png

Hope this Helps.
Regards
Alen

 

0 Likes
lock attach
Attachments are accessible only for community members.
stan4233_475378
Moderator
Moderator
Moderator
25 replies posted 10 questions asked 50 sign-ins

Hello Alen,

Thanks a lot for your quick reply.  I have learnt something useful from your answer.  However, as your answer had avoided using the Makefile / LIBNAME approach, I wanted to get back to understand how to use LIBNAME properly.  LIBNAME was described briefly in the Modus Toolbox documentation but not to a sufficient depth (such as providing a full example).

So I have updated libhello-demo (https://github.com/mtb04313/libhello-demo) to add a dependency module: world-deps-demo (https://github.com/mtb04313/world-deps-demo).  My actual project code requires several such dependencies, but here, I have used a simplified example.  "make getlibs" does a neat job in pulling these dependencies to mtb_shared and I don't want to lose this capability.

libhello_api.c now requires world_api.c

bool test_me(void) {

    return test_world();

}

I have attached the updated steps (steps_updated_deps.zip)

My 3 questions are still the same, but I would like to request a solution based on using the Makefile / LIBNAME approach. 

Thanks!

Best Regards,

SK

0 Likes
AlenAn14
Moderator
Moderator
Moderator
500 replies posted 100 solutions authored 250 replies posted

The approach using LIBNAME would be difficult for this purpose as when using the project MakeFile , it expects the TARTGET field which if specified will require you to fetch the related dependency files (cata, cat1a, etc) . This is because you are creating a static library of an application and not a static library file from already existing .c and .h files (The method I suggested above) which is why you have to first create the application with the APPNAME command in the first build and then comment this and then give the LIBNAME on the next build so that it has an application that it can convert to a static library.

Since you require pulling your custom library from GitHub, I would recommend you to use the manifest file approach. For this you can read the section 6.2.2, Secondary super-manifest and section 6.4, Access Private Repositories of the ModusToolbox User Guide. (You can check section 6.2 to understand how to create your own manifest files. In this section, they have provided links to manifest files which you can use as templates to create your own).

Hope this helps.
Regards
Alen

0 Likes
AlenAn14
Moderator
Moderator
Moderator
500 replies posted 100 solutions authored 250 replies posted

Post Check.

0 Likes
lock attach
Attachments are accessible only for community members.
stan4233_475378
Moderator
Moderator
Moderator
25 replies posted 10 questions asked 50 sign-ins

Hello Alen,

Currently with the default manifests, I'm able to pull Github dependencies, so I'm not sure how using custom manifest files will help. Are you suggesting I should make a custom TARGET?

I found a workaround for my problems and wanted to share the answers to the 3 questions.

1. to use LIBNAME=libhello, I first have to include in the deps sub-folder:

core-lib.mtb
core-make.mtb
mtb-pdl-cat1.mtb
psoc6cm0p.mtb
recipe-make-cat1a.mtb

I 'copied' these files from the libs sub-folder (from the APPNAME case).

2. I retained the TARGET definition in the Makefile, but added a .cyignore so as to avoid building unnecessary code.

# .cyignore
$(CY_GETLIBS_SHARED_PATH)$(CY_GETLIBS_SHARED_NAME)/TARGET_CY8CPROTO-062-4343W/
$(CY_GETLIBS_SHARED_PATH)$(CY_GETLIBS_SHARED_NAME)/mtb-pdl-cat1/
$(CY_GETLIBS_SHARED_PATH)$(CY_GETLIBS_SHARED_NAME)/psoc6cm0p/

3. the resultant .a does not have any BSP code and should be usable across all M4 projects (though I'm unsure about M0).

Building 2 file(s)
Compiling app file libhello_api.c
Compiling ext file world_api.c
Archiving output file libhello.a

I have updated libhello-demo (https://github.com/mtb04313/libhello-demo) and attached the steps (steps_optimized.zip).

Thanks!

Best Regards,
SK

HI @stan4233_475378 ,

Thanks for sharing this workaround with the community.
The .cyignore usage for your purpose is accurate for preventing the inclusion of the target BSP files (.c and .h files under the target folder in mtb_shared folder) in the build process that are pulled as part of the dependencies although you cannot prevent the BSP source files from being pulled when using this method (causing the increased latency for pulling the BSP source files which are not used during 'make build' command ) as the TARGET is necessary for the make procedure.

You can mark your response as the solution so we can close this thread.

Thanks & Regards
Alen

0 Likes