Fix that deal where if you include one file from a library folder it includes the entire folder

Lots of those virtual functions I was warning about. Even a Virtual distructor, which I don’t really understand and definitely don’t know how will affect the dependency tree for the linker optimizations that I’m expecting to save you :frowning:

Also, not an “Arduino library.” (I DON’T think it would work better even if you added the Arduino library “stuff” around it, though.)

Do you have a sample client sketch as well?

jimLee:
No, I have not tried the dot linkage.

-jim lee

https://arduino.github.io/arduino-cli/library-specification/#libraryproperties-file-format

These are the things you would need to change in your library to test the "dot_a_linkage" mode:

Move the source files to the src subfolder

Add a file to the root of the library named library.properties. For the most part, the content of this file doesn't matter as long as it contains all the required fields.

Add to the library.properties file, the following line:

dot_a_linkage=true

The full library.properties could look something like this:

name=LC_quickCom
version=1.0.0
author=Jim Lee
maintainer=Jim Lee
sentence=Library for master/slave communication
paragraph=
category=Communication
url=https://github.com/leftCoast/LC_quickCom
architectures=*
dot_a_linkage=true

The library structure would now look like this:

LC_quickCom |_ README.md |_ library.properties |_ src |_ commonComs.cpp |_ commonComs.h |_ quickCom.cpp |_ quickCom.h

It should take less than 5 minutes to make the changes to the library and try it out.

Adding the library.properties file will also make it possible for you to add your library to the Arduino Library Manager index if you like.

Allright, I'll give it a try.

As for virtual destructors. from what I've been lead to believe they won't work if they are not virtual. From what I understand the virtual part is what allows them to "roll up" their dependancies when they are deleted.

As for a simple sample client sketch, not at the moment. I originally developed this for the cell phone. Used for talking from my main processor, the teensy, to the feather FONA. The cellphone codebase is massive, it even has dynamic loading and unloading of sketches into RAM, like applications. So it would be a terrible example. The Feather FONA is just a a bunch of command handlers. So at least its harder to hide stuff in.

The FeatherFONA sketch : cellPhone_IV.ino

And for the curious, the cell phone GUI : cellPhone_VI

I got into a "discussion" a few days ago when I said you could swap sketches in and out of RAM. Its in this last link above how I did that.

-jim lee

Ok, setup the quickCom library with the .properties file and the src folder etc. And IF I put the common .h file between the two processors in there, it works.

But here's the issue. What to do with these common .h files? They are specific to EACH project I'm (you're) using the library for.. This does NOT belong in the quickCom library folder. But most anywhere I put one, it acts like a vacuum and sucks all those source files etc into the project overrunning the code and RAM space. Do I now have to put "special" library folders in my library for each of the projects that use quickCom?

And, seeing that it does overrun your code space, I don't think your linker is doing a very good job of code stripping.

Lets simplify this a bit

I have 2 projects, project A & project B. They run on different processors. How do I share a .h file between them?

-jim lee

I like how you went the extra mile and added the "depends" field to library.properties! Even if the dot_a_linkage thing doesn't end up being useful to you, it looks like the effort to add the library.properties won't have been a waste. This file is also required for people to use the library on Arduino Web Editor.

jimLee: IF I put the common .h file between the two processors in there, it works.

Is this the "common .h file"?: https://github.com/leftCoast/LC_quickCom/blob/master/src/cellCommon.h

Yeah, I saw that and liked the idea behind it. "If I use this, I'll need to pull in all these as well." Kinda' thing.

I still have no real idea what the .a stuff is all about. If it helps so much, why default it to off? What is it buying you to not have it.

But then, IDEs have ALWAYS been one of my weakest points. Getting to "hello world" or "Blink the LED" is nothing but a daunting nightmare for me.

When I ran across Arduinos.. About 6 years ago? The entire start()..loop(), with example blink, was bait in the trap.

Anyway, thanks for going out and having a look! Its good to know someone is keeping tabs on progress. :)

-jim lee!

jimLee: I still have no real idea what the .a stuff is all about. If it helps so much, why default it to off? What is it buying you to not have it.

The .a is a precompiled archive of the library. To use this feature, the library author must compile the library for every target architecture. So it's not just some magical switch you turn on in library.properties. It takes effort from the library author to generate these .a files and put them in the correct folder structure, then that effort needs to be done over again on every release. It's not a huge amount of work, but many hobby developers already don't have enough time to properly maintain their projects.

Many Arduino libraries (including yours from what I can see at a glance) are non-architecture specific, so precompiling it for every architecture it could possibly be used with would be challenging.

The whole idea of supporting precompiled Arduino libraries is a bit controversial because it permits closed source libraries. Officially adding this capability to the Arduino build system was specifically prohibited for some time. However, there is a legitimate use for this feature beyond "you can use my precious library, but you're not allowed to look at the top secret code": precompiling large libraries saves a lot of time on the compilation process for sketches that use it. There is now a "precompiled=full" setting that allows providing precompiled versions for specific target architectures, but also having the builder fall back to using the source files when compiling for a board that precompiled files weren't provided for.

Even though it's unfortunate to see closed source libraries, there are some cases where this is all we have available. Some chip manufacturers have an unfortunate habit of not making their libraries open source, so you either need to work with the closed source library or nothing at all (unless you can manage some genius level reverse engineering to write your own). The precompiled feature allows the creation of "mixed source" libraries where a community member is able to create an Arduino library that wraps a closed source binary with open source code, extending the functionality or providing a more user friendly interface.

I've recently done some work to try to fully document this feature and make it a bit easier to understand. That was done after the "0.11.0" release of the documentation, so the new content is only visible when viewing the documentation with "dev" selected from the version menu: https://arduino.github.io/arduino-cli/dev/library-specification/

Please let me know if you find anything in specific to be unclear.

When I added the .a flag to my library, that library suddenly didn’t have the vacuum .h issue. But I also didn’t have to tell it what kind of processor I was compiling for. Well, I guess I did when I chose what to compile for.

Now, I don’t see any .a files in my library, so I guess they were used and deleted?

So… From my point of view. I switched a flag, it “did something”. I don’t see any changes except… The vacuum .h issue is gone. What part am I missing? Why would I need to compile this for everyone? It seems its done automatically whenever it compiles.

I like open source. It makes using the stuff SO much easier! You can see what they were thinking when they wrote it.

The old MetroWerks IDE’s code came as source. It also automatically precompiled everything and that sped things up considerably.

-jim lee

Ah, I understand now what you mean by “the .a stuff”: the “dot_a_linkage” field of library.properties. Since it was in the context of talking about other features of library.properties, I thought you were referring to the “precompiled” field.

jimLee:
Now, I don’t see any .a files in my library, so I guess they were used and deleted?

That’s correct. They are compiled to the temporary build folder, and then deleted when the temporary folder is cleared. You can find the location by turning on verbose output during compilation.

This actually does provide an easy way for library authors to generate the .a files for use with the “precompiled” feature, so in that way the two are related.

jimLee:
Why would I need to compile this for everyone? It seems its done automatically whenever it compiles.

You would need to compile it for everyone if you didn’t want each of them to have to wait for the library to be compiled when they use it in a sketch. In this case, it’s likely the time required to compile your library is very fast, and so doing that really wouldn’t provide much benefit.

jimLee: Yeah, I saw that and liked the idea behind it. "If I use this, I'll need to pull in all these as well." Kinda' thing.

I still have no real idea what the .a stuff is all about. If it helps so much, why default it to off? What is it buying you to not have it.

almost all my previous comments were about it

Yes, and I appreciate how frustrating it must be to try to explain it to me who has such a rough time understanding all of it.

So lets see if I got it?

There are two ways to compile a library, with the .a on and with it off.

From what I can see, the net result is…

With it on, the compiler/linker is more careful about adding just the code that pertains to the project in process.
With it off, it dumps in everything it sees into the project in progress.

I got that right?

-jim lee

jimLee: Yes, and I appreciate how frustrating it must be to try to explain it to me who has such a rough time understanding all of it.

So lets see if I got it?

There are two ways to compile a library, with the .a on and with it off.

From what I can see, the net result is..

With it on, the compiler/linker is more careful about adding just the code that pertains to the project in process. With it off, it dumps in everything it sees into the project in progress.

I got that right?

-jim lee

yes. the way how Arduino IDE uses the code of libraries could be seen as error so your complaint was a rightful one. the dot-a-linkage fixes this, but some libraries would not link right from .a so the dot-a-linkage can't be made default.

what is the difference: - if you give the linker .o files (result of compiling a .cpp, .c, .S ... file) it takes all the global variables and associated code . - if the linker has .o only for the sketch and .a for libraries, it searched in .a only for code referred from the .o and ignores all other .o inside .a (.a is a collection of .o)

I bumped into this in Eclipse Sloeber. It is so compatible with Arduino IDE that it too puts all the .o at linker commend line. But Sloeber doesn't support the .a linkage yet so I had problems with the NicoHood HID library, which doesn't work without .a linkage because it has more global HID interfaces then allowed and with .a linkage only the USB interfaces used by the sketch are initialized.