Giter Club home page Giter Club logo

Comments (5)

me-no-dev avatar me-no-dev commented on August 19, 2024

I do not see this as option for ArduinoIDE. All "Arduino" source is open and compiled at build (well... before arduino-builder the ide used to build the lib and not rebuild unless changed, but now it'a always rebuilt). Having users use a prebuilt lib would mean that there will be no c/cpp source files in the core. Would also mean that any changes to the defines in the headers will not propagate to the core (like enable debug and so on). Having a lib for linux users who want to use the api for RaspberryPi development is OK, but separate from all other users who will build it using ArduinoIDE, Eclipse, PlatformIO or whatever else on another machine.
As a power user I would hate to have to use provided libraries and not be able to alter and change the source (I do not know how much you know of the issues we have with ESP8266 and not having the source for most of the network related libs).
As a person who wants to contribute to the project, I would hate to have to change build settings, just to test and run a new feature/bugfix that I want to to submit a pull request for. Not to mention that the changes required would also propagate to the changed files in the pull request.
There is another aspect to look at also. Arduino, as it is, is a mixture of C and C++ files. Libs for those should be separate. The C core needs to be build as a libPiDuino.so and the C++ files should be in libPidDuino++.so, so the libs can be used by both C and C++ apps. As a matter of fact, I see less people using the libraries rather than the Arduino approach because for native apps there are kernel APIs to do all you want and it to be working on more than one platform (portable).

from raspiarduino.

nkolban avatar nkolban commented on August 19, 2024

Can we think of any sketch building options which would change the outcome of generated code that comes from core? For example, what might I possibly place in a sketch that would result in different generated code from any of the source files compiled from core? I'm not saying that there aren't any, I just can't think of a single example.

If I understand how the IDE works today, we tell it the directories containing code that should be compiled together to form an executable. Today, this includes core ... as such, everything in core is compiled and then link-edited together. For a sketch that doesn't use a particular function, doesn't that mean that we waste effort compiling core files when we aren't going to need them? If only the sketch code were compiled at compile time and resolved what it needed from libraries, would that not solve the problem?

I would imagine that the source of the core and other files would also be supplied with the project including a make file to compile the libraries from the source. I'm just not yet seeing the need to compile them for each sketch.

For separate C and C++ libraries ... I'm not seeing it ... why can't we have one library that contains object files from both C and C++ compiles? Can C named functions not be declared in a header with extern "C" so that they can be used in a C++ app?

What is going through my mind is the end user experience ... I believe that most end users will want to compile sketches ... and if having sketches linked with pre-compiled libraries vs having sketches compile and then link with source files would produce any kind of different end user experience when building sketches ... then I'm convinced ... but I'm not seeing it yet.

For compilation with debugging ... I'm thinking it would be either compile time debugging with "-g" for gdb which could be left on in the libraries but stripped should that not be needed in finalized executables.

For community modification to the libraries, I'm thinking that the source of all the libraries would be supplied as well and if a power user wishes to make a change to a core provided library (which I believe to be rare ... unless they are making a change for re-contribution back to the project) ... then they can make the change and run the projects makefile to build the new libraries.

The benefits (as I see them) for the solution is that the time between pressing build and being ready to run will be less because we won't be recompiling code previously built. Another advantage is that if we link with libraries that contain the core ... then a fix or enhancement will immediately be taken advantage of by other sketches that have previously been built without having to recompile the sketches themselves.

from raspiarduino.

me-no-dev avatar me-no-dev commented on August 19, 2024

Just look at any Arduino implementation for Any MCU. Look at the git repositories that host them. Look at the commit frequency. Look at the bug reports. The Arduino world does not work with libraries. And I can give you many examples where we daily need to enable particular debug in the core to figure out what we are doing wrong. This would be impossible or at least really uncomfortable to do if using prebuilt libraries.
There are 0 projects doing what you are saying and there is nothing in gain but a few seconds for compile.
Computers are so powerful nowadays that compilation takes far less than the upload process.

from raspiarduino.

me-no-dev avatar me-no-dev commented on August 19, 2024

Can you compile C app and link it to C++ library? If your answer is yes, then one lib can do

from raspiarduino.

nkolban avatar nkolban commented on August 19, 2024

Since this issue if implemented or not implemented will not change the end user experience while using the Arduino IDE other than some small additional time spent or not spent compiling the core code ... I think we can put it to one side until and unless we decide to revisit it again with experience behind us on how the community adopts the project.

A smart man once told me that worrying about puzzles like this one was like worrying about the overpopulation problem on Mars.

We now have issue #33 in our mix which I believe to be more immediate and will change the end user pattern and options of work. I suggest that we put aside this issue (#32) and see where we go with Issue #33.

from raspiarduino.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.