Open nkolban opened 8 years ago
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).
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.
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.
Can you compile C app and link it to C++ library? If your answer is yes, then one lib can do
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.
This issue suggests the construction of pre-compiled code for PiDuino supplied C source. The high level is that all the C and CPP supplied with PiDuino that constitutes the Core libraries and utilities be pre-compiled and placed in an archive for linking. This will be either (or both) a static library or a dynamic shared library.
The thinking is two fold:
1) There is no obvious reason that this code need be compiled each time that a new user supplied sketch is built. When a new sketch is supplied, we should only compile that sketch and "link" with the library. 2) By creating a library of the core, we now have the opportunity for code developers who merely wish to use the PiDuino libraries without going through the Arduino IDE to do so simply by compiling their own code and linking with the PiDuino library.
An initial thought on the name of the library is:
The impact of this issue is high. It will change the core nature of the project. The build environment for the IDE will change and the project will now also have to include an extra build system for those that wish to build the library from the supplied source.