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

jimLee:
Now if they fix that deal where if you include one file from a library folder it includes the entire folder. I'd be all over it!

How would you want it to work?

pert:
How would you want it to work?

That may be an interesting question but it is a distraction from the subject of this Thread. May I suggest starting a separate Thread if you want to pursue it?

...R

jimLee:
Now if they fix that deal where if you include one file from a library folder it includes the entire folder. I'd be all over it!

it doesn't do that in general

Cunfuzed by dis post ?

Seems to be a continuation of a post that is now a seperate post ?

Sorry for the confusion. My Internet went out before I got a chance to add a note explaining what had happened.

There happens to be an active discussion right now regarding the idea of offering the ability to exclude library files from recursive compilation:

That is for the Arduino CLI, but all the Arduino development software (Arduino IDE, Arduino Web Editor, Arduino Pro IDE) uses Arduino CLI, so features added to Arduino CLI become available to the IDEs.

I don't remember having seen any requests for this sort of feature prior to that GitHub issue. So it's interesting to determine whether the desire for this is widespread, as well as to get any ideas for how it might be implemented.

I was a Mac developer for a long time. In the end we were using Code Warrior and their PowerPlant c++ application framework. If you are familiar with this, it'll give you a good idea for what I am used to.

From what I recall, from a "user" point of view was that the code included in your build was in a project file list that was editable. Also your code had to list, in the source files, what it needed using the standard #include statements. Easy to use, easy to control.

What I've run into here, for example, is writing code for two processors. Master/Slave I have both sides (classes) in the same library folder because they are a pair, and they also need common .h files so that you know things will match. But, one processor is bigger and has more responsibility and there is more leeway on how you write its code. The other is small and you need to be more careful with the code. (Being very careful of RAM) The Arduino IDE Dumps ALL of the code into both processors. Completely overfilling the poor little one.

So I have a hard time with the auto selection of source code. I understand why its done that way because for a new coder it makes things a LOT easier. But in certain situations, like this, it wold be nice to be able to specify what goes in what sketch.

-jim lee

@jimLee, did you try dot_a_linkage in library.properties?

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

without .a the builder puts all .o files on linker command line.
with .a for a library, the .a file is put on linker command line and the linker uses only required .o files from the .a file.

@juraj Sorry, that went right over my head.

-jim lee

jimLee:
@juraj Sorry, that went right over my head.

-jim lee

if you build with normal c++ toolchain, the libraries are in form of archive files with extension .a. this contains the individual compiled compilation units in form of object .o files. at default arduino builder doesn't create .a files for libraries, but sends all .o files to linker.

if the linker has .o files on command line and this file contains a global variable, the it is put in the final linked file. if the linker searches or dependencies in .a archives, then it picks from .a only the .o files on which the .o files from linker command line depend.

So it solves the multiplatform library use case you described.

Hi, sorry, took a long break from this..

@Juraj Lets look at this from a simple user point of view. I'm good at this because I'm a really simple user.

All I know is that if I follow c++ rules, the IDE cooks up machine code that does what I asked for. And, it loads my Arduino with that. (Making me very happy!)

Now, in my list of c++ rules I can add in a library. As far as I can tell, or care, this is done by including the .h files for the code I want to add. You can't have code without it being defined. And its all defined in the .h files. Ok ok, I could define it in my .ino file and have it link in the .cpp stuff, but lets leave that aside for now.

So, the rule I'd like to be able to follow is : Beyond the standard libraries that Arduino automatically adds to my code, only link in code that is in my .ino file, and, this is the important part, the .cpp files that match up to my .h files. This way I have complete control over what I'm adding, and what I want to exclude [in my simple c++ world].

When you start going on about linkers and .a files .o files.. Its just confusing noise. All of that is outside of my c++ world that runs c++ rules.

And I guess that's what I was originally expecting and what I'm asking for.

But why not use the linker trick? Because now, nothing I do would be "standard". I have to learn this technique to make it work. And worse than that, I have to teach it to EVERY PERSON that wants to use my code. Not a feasible solution.

Sorry to take so long to reply.

-jim lee

you started this with "Now if they fix that deal where if you include one file from a library folder it includes the entire folder. I'd be all over it!"
I say they fixed it, but they can't apply it to all libraries, because for some of the libraries the result is different.
so it is on library authors and maintainers to set the parameter in their library.properties

What do you mean? DO you have an example of a .h file that covers multiple .cpp files? I'm just having an issue with the fact that one .h defaults to dumping in the entire folder of code.

-jim lee

You realize that that “entire folder of code” will have all the parts that aren’t actually used discarded during the final stages of the build (“linking”). It’s mildly annoying from a build time/noise perspective, but it’s not bloating you final code size unless it needs to...

jimLee:
What do you mean? DO you have an example of a .h file that covers multiple .cpp files? I'm just having an issue with the fact that one .h defaults to dumping in the entire folder of code.

-jim lee

that is one of the base principles of Arduino. the Arduino simplification of use of libraries. using the .h file you add the library. there is no makefile to list the files.

westfw:
You realize that that “entire folder of code” will have all the parts that aren’t actually used discarded during the final stages of the build (“linking”). It’s mildly annoying from a build time/noise perspective, but it’s not bloating you final code size unless it needs to...

Not true. What started this was a library I wrote that does master/slave communication. Each side ended up a bit different in that master processors tend to be bigger and slave processors tend to be smaller etc. They shared a common .h file and this caused everything to be dumped into both, completely burying the poor slave processor's RAM. The code may be stripped down by the linker, but the globals do not seem to be. Therefore, the part you want to spend most dearly, is wasted.

-jim lee

This caused everything to be dumped into both, completely burying the poor slave processor's RAM. The code may be stripped down by the linker, but the globals do not seem to be.

The globals should be stripped.
I added some dummy code and globals to SoftwareSerial, and it seems to behave the way I expect.

Could you provide a sample library and example sketch that behaves the way you're describing?

jimLee:
DO you have an example of a .h file that covers multiple .cpp files?

I do. I just grabbed the first library listed under the arduino-libraries GitHub organization, so it's not at all cherry-picked:

This file contains declarations for both Ethernet.cpp and socket.cpp.

Here's the library in question. LC_quickCom
Note: You can ignore LC_commonComs, they didn't exist when I hit this issue.

The trouble happened when I tried to share a .h file between the two processors that defined the command set I wanted to use.

Here is the .h file I wanted to include for each processor. (teensy 3.2 master and Adafruit FeatherFONA slave)

#ifndef cellCommon_h
#define cellCommon_h

#define CID_BUFF_BYTES  20

enum cellCommands { getStatus, setCurrentPN, sendSMS, getSMS, makeCall, hangUp, pickUp, setVolume, chooseRing, touchTone, somethingElse  };

enum networkStatus { NS_notRegistered, NS_registeredHome, NS_registeredSearching, NS_denied, NS_unknown, NS_registeredRoaming };

enum callStatus  { CS_ready, CS_noStatus, CS_unknown, CS_ringingIn, CS_ringingOut };

struct cellStatus {
  uint16_t    FONAOnline;
  uint16_t    batteryVolts;
  uint16_t    batteryPercent;
  uint16_t    RSSI;
  uint16_t    networkStat;
  uint16_t    volume;
  uint16_t    callStat;
  uint16_t    numSMSs;
  char        callerID[CID_BUFF_BYTES];
  uint16_t    statNum;
  uint16_t    errByte;
};
 
 
struct tone {
  uint16_t  freq;
  uint16_t  durationMS;
};


#endif

Thanks for taking an interest and looking at this stuff.

-jim lee

jimLee:
Not true. What started this was a library I wrote that does master/slave communication. Each side ended up a bit different in that master processors tend to be bigger and slave processors tend to be smaller etc. They shared a common .h file and this caused everything to be dumped into both, completely burying the poor slave processor's RAM. The code may be stripped down by the linker, but the globals do not seem to be. Therefore, the part you want to spend most dearly, is wasted.

-jim lee

and did you try the dot_a_linkage?

No, I have not tried the dot linkage.

-jim lee