When I download C source code (for example for Linux), most of the time I need to use make (or autoconf). In embedded world (no Linux embedded), we use MCUs produced by a silicon vendor that give you at least a ready-to-use IDE (Elipse based or Visual Studio based or proprietary). Recently it give you a full set of libraries, middlewares, tools to create a complex project from scratch in a couple of minutes that is compatibile and buildable with its IDE. Ok, it's a good thing to start with a minimal effort and make some tests on EVB and new chips. However I'm wondering if a good quality commercial/industrial grade software is maintained under the IDE of the silicon vendor or it is maintained with a Makefile (or similar). I'm asking this, because I just started to add some unit tests (to run on the host machine) on one of my projects that is built under the IDE. Without a Makefile is very difficult to add a series of tests: do I create a different IDE project for each module test? Moreover, the build process of a project maintained under an IDE is manual (click on a button). Most of the time there isn't the possibility to build by a command line and when it is possible, it isn't the "normal" way. Many times in the past I tried to write a Makefile for my projects, but sincerely for me make tool is very criptic (tabs instead of spaces?). Dependencies are a mess. Do you use IDE or Makefile? Is there a recent and much better alternative to make (such as cmake or SCons)?
Makefile or IDE?
Started by ●December 2, 2021
Reply by ●December 2, 20212021-12-02
On 2021-12-02, pozz <pozzugno@gmail.com> wrote:> Ok, it's a good thing to start with a minimal effort and make some tests > on EVB and new chips. However I'm wondering if a good quality > commercial/industrial grade software is maintained under the IDE of the > silicon vendor or it is maintained with a Makefile (or similar).We always use makefiles. Some people do their editing and "make"ing in an IDE like eclipse. Others use emacs or whatever other environment they like. In my experience, software provided by silicon vendors has always, been utter crap. That's been true for IDEs, libraries, header files, debuggers -- _everything_. And it's been true for 40 years. Recently I tried to use the Silicon vendor's IDE and demo project/libraries to build the simple app that prints "hello world" on a serial port. This is an application, IDE, and libraries the silicon vendor provided _with_the_evaluation_board_. Following the instructions, step-by-step, did allow me to build an executable. It was far too large for the MCU's flash. I threw out the silicon vendor's "drivers" (which were absurdly bloated) and C library (also huge). I wrote my own bare-metal drivers and substituted the printf() implementation I had been using for years. The exectuable size was reduced by over 75%. We've also tried to use non-silicon-vendor IDEs (eclipse), and using the IDE's concept of "projects" is always a complete mess. The "project" always ends up with lot's of hard-coded paths and host-specific junk in it. This means you can't check the project into git/subversion, check it out on another machine, and build it without days of "fixing" the project to work on the new host. -- Grant
Reply by ●December 2, 20212021-12-02
Il 02/12/2021 16:22, Grant Edwards ha scritto:> On 2021-12-02, pozz <pozzugno@gmail.com> wrote: > >> Ok, it's a good thing to start with a minimal effort and make some tests >> on EVB and new chips. However I'm wondering if a good quality >> commercial/industrial grade software is maintained under the IDE of the >> silicon vendor or it is maintained with a Makefile (or similar). > > We always use makefiles. Some people do their editing and "make"ing in > an IDE like eclipse. Others use emacs or whatever other environment > they like. > > In my experience, software provided by silicon vendors has always, > been utter crap. That's been true for IDEs, libraries, header files, > debuggers -- _everything_. And it's been true for 40 years. > > Recently I tried to use the Silicon vendor's IDE and demo > project/libraries to build the simple app that prints "hello world" on > a serial port. This is an application, IDE, and libraries the silicon > vendor provided _with_the_evaluation_board_. > > Following the instructions, step-by-step, did allow me to build an > executable. It was far too large for the MCU's flash. I threw out the > silicon vendor's "drivers" (which were absurdly bloated) and C library > (also huge). I wrote my own bare-metal drivers and substituted the > printf() implementation I had been using for years. The exectuable > size was reduced by over 75%. > > We've also tried to use non-silicon-vendor IDEs (eclipse), and using > the IDE's concept of "projects" is always a complete mess. The > "project" always ends up with lot's of hard-coded paths and > host-specific junk in it. This means you can't check the project into > git/subversion, check it out on another machine, and build it without > days of "fixing" the project to work on the new host.Thank you for sharing your experiences. Anyway my post wasn't related to the quality (size/speed efficiency...) of source code provided by silicon vendors, but to the build process: IDE vs Makefile.
Reply by ●December 2, 20212021-12-02
On 12/2/2021 4:46 AM, pozz wrote:> When I download C source code (for example for Linux), most of the time I need > to use make (or autoconf). > > In embedded world (no Linux embedded), we use MCUs produced by a silicon vendor > that give you at least a ready-to-use IDE (Elipse based or Visual Studio based > or proprietary). Recently it give you a full set of libraries, middlewares, > tools to create a complex project from scratch in a couple of minutes that is > compatibile and buildable with its IDE. > > Ok, it's a good thing to start with a minimal effort and make some tests on EVB > and new chips. However I'm wondering if a good quality commercial/industrial > grade software is maintained under the IDE of the silicon vendor or it is > maintained with a Makefile (or similar). > > I'm asking this, because I just started to add some unit tests (to run on the > host machine) on one of my projects that is built under the IDE. Without a > Makefile is very difficult to add a series of tests: do I create a different > IDE project for each module test? > > Moreover, the build process of a project maintained under an IDE is manual > (click on a button). Most of the time there isn't the possibility to build by a > command line and when it is possible, it isn't the "normal" way. > > Many times in the past I tried to write a Makefile for my projects, but > sincerely for me make tool is very criptic (tabs instead of spaces?). > Dependencies are a mess. > > Do you use IDE or Makefile? Is there a recent and much better alternative to > make (such as cmake or SCons)?Makefiles give you more control over the build/test/document process. They're "code" of a different sort (and purpose). Otherwise, you are left at the mercy of whoever designed/implemented the tool(chain) you are using. [I have makefiles that ship my sources off to other machines and start builds, there, to verify that my code at least compiles without warnings on different architectures -- before getting to "invested" in the current state of the code] There are tools that will help you create makefiles. The biggest problem (with inheritted codebases) will be if you have to use a particular "flavor" of make. Or, some oddball build *system*. (converting from something like that to a more "standardized" build environment can often be a significant effort. So, if the foreign codebase is something that is still actively being maintained, you may choose to adopt its oddball way of doing things to save yourself from having to keep "porting" the build mechanism(s) over to "your" way of doing things -- even if that is a friendlier environment!
Reply by ●December 3, 20212021-12-03
Il 02/12/2021 17:34, Stefan Reuther ha scritto:> Am 02.12.2021 um 12:46 schrieb pozz: >> Moreover, the build process of a project maintained under an IDE is >> manual (click on a button). Most of the time there isn't the possibility >> to build by a command line and when it is possible, it isn't the >> "normal" way. > > So far, all the IDEs I have encountered this century use some variation > of make under the hood, and have a somewhat standard compiler (i.e. > responds to `whatevercc -c file.c -o file.o`). > >> Many times in the past I tried to write a Makefile for my projects, but >> sincerely for me make tool is very criptic (tabs instead of spaces?). >> Dependencies are a mess. >> >> Do you use IDE or Makefile? Is there a recent and much better >> alternative to make (such as cmake or SCons)? > > Think of make (or ninja) as some sort of (macro-) assembler language of > build systems, and add a high-level language on top. > > CMake seems to be a popular (the most popular?) choice for that language > on top, although reasons why it sucks are abundant; the most prominent > for me being that the Makefiles it generates violate pretty much every > best practice and therefore are slow. Other than that, it can build > embedded software of course. > > You'll eventually need another meta-build system on top to build the > projects that form your system image (busybox? openssl? dropbear? > linux?), you'll not port their build systems into yours.It's very difficult to choose the build system today to study and use. make, Cmake/make, Cmake/ninja, Meson, Scons, ... What do you suggest for embedded projects? Of course I use cross-compiler for the target (mainly arm-gcc), but also host native compiler (mingw on Windows and gcc on Linux) for testing and simulation.
Reply by ●December 3, 20212021-12-03
On 2.12.21 18.34, pozz wrote:> Il 02/12/2021 16:22, Grant Edwards ha scritto: >> On 2021-12-02, pozz <pozzugno@gmail.com> wrote: >> >>> Ok, it's a good thing to start with a minimal effort and make some tests >>> on EVB and new chips. However I'm wondering if a good quality >>> commercial/industrial grade software is maintained under the IDE of the >>> silicon vendor or it is maintained with a Makefile (or similar). >> >> We always use makefiles. Some people do their editing and "make"ing in >> an IDE like eclipse. Others use emacs or whatever other environment >> they like. >> >> In my experience, software provided by silicon vendors has always, >> been utter crap. That's been true for IDEs, libraries, header files, >> debuggers -- _everything_. And it's been true for 40 years. >> >> Recently I tried to use the Silicon vendor's IDE and demo >> project/libraries to build the simple app that prints "hello world" on >> a serial port. This is an application, IDE, and libraries the silicon >> vendor provided _with_the_evaluation_board_. >> >> Following the instructions, step-by-step, did allow me to build an >> executable. It was far too large for the MCU's flash. I threw out the >> silicon vendor's "drivers" (which were absurdly bloated) and C library >> (also huge). I wrote my own bare-metal drivers and substituted the >> printf() implementation I had been using for years. The exectuable >> size was reduced by over 75%. >> >> We've also tried to use non-silicon-vendor IDEs (eclipse), and using >> the IDE's concept of "projects" is always a complete mess. The >> "project" always ends up with lot's of hard-coded paths and >> host-specific junk in it. This means you can't check the project into >> git/subversion, check it out on another machine, and build it without >> days of "fixing" the project to work on the new host. > > Thank you for sharing your experiences. Anyway my post wasn't related to > the quality (size/speed efficiency...) of source code provided by > silicon vendors, but to the build process: IDE vs Makefile.They are not complete opposites For example, the Eclipse CDT uses make at the tool to perform the build. There is a difference whether the user wirites the makefiles or the IDE creates them. Most IDEs create makefiles for running the generated code on the same computer which houses the IDE, and it is more difficult to cross-compile for embedded targets. I agree on the silicon manufacturers' code, it should be jettisoned. I have abandoned the code from both Atmel and ST after fighting some weeks to make them perform. Instead, the manufacturers should concentrate on documenting the hardware properly. I had to dis-assemble Atmel's start-up code to get the fact that SAM4 processor clock controls must be changed only one field at a time, even if the fields occupy the same register. If multiple fields were changed, the clock set-up did never get ready. This is a serious problem, as ARM breaks the JTAG standard and requires the processor clock running to respond to JTAG. The JTAG standard assumes that the only clocking needed comes from the JTAG clock. -- -TV
Reply by ●December 3, 20212021-12-03
Am 03.12.2021 um 11:49 schrieb pozz:> Il 02/12/2021 17:34, Stefan Reuther ha scritto: >> Think of make (or ninja) as some sort of (macro-) assembler language of >> build systems, and add a high-level language on top. >> >> CMake seems to be a popular (the most popular?) choice for that language >> on top, although reasons why it sucks are abundant; the most prominent >> for me being that the Makefiles it generates violate pretty much every >> best practice and therefore are slow. Other than that, it can build >> embedded software of course. >> >> You'll eventually need another meta-build system on top to build the >> projects that form your system image (busybox? openssl? dropbear? >> linux?), you'll not port their build systems into yours. > > It's very difficult to choose the build system today to study and use. > > make, Cmake/make, Cmake/ninja, Meson, Scons, ... > > What do you suggest for embedded projects? Of course I use > cross-compiler for the target (mainly arm-gcc), but also host native > compiler (mingw on Windows and gcc on Linux) for testing and simulation.Same here. At work, we use cmake/make for building (but if you have cmake, it doesn't matter whether there's make or ninja below it). That's pretty ok'ish for turning a bunch of source code files into an executable; probably not so good for doing something else (e.g. rendering images for documentation and your device's UI). Personally, I generate my Makefiles (or build.ninja files) with a homegrown script; again, based on the assumption that make is an assembler that needs a high-level language on top. However, building your code isn't the whole story. Unless you have a huge monorepo containing everything you ever did, you'll have to check out different things, and you will have dependencies between projects, some even conditional (maybe you don't want to build your unit test infrastructure when you make a release build for your target? maybe you want a different kernel version when building an image for a v2 board vs. a v1 board?). I use a tool called 'bob' <https://github.com/BobBuildTool/bob> as the meta-build system for that, at work and personally. It started out as an in-house tool so it surely isn't industry standard, needs some planning, and then gets the job done nicely. It invokes the original build process of the original subprojects, be it cmake-based or autotools-based. The people who build (desktop or embedded) Linux distributions all have some meta-build system to do things like that, and I would assume neither of them is easy to set up, just because the problem domain is pretty complex. Stefan
Reply by ●December 3, 20212021-12-03
pozz <pozzugno@gmail.com> wrote:> Do you use IDE or Makefile? Is there a recent and much better > alternative to make (such as cmake or SCons)?ISTM that IDEs start off as cover for the woeful state of the command line environment on Windows. On Unix, when you want to target a different platform, all you need is a new compiler. Just grab arm-unknown-gnueabi-gcc and you're done. Maybe you need some libraries as well, but that's easy. Debugging tools are all there - based on gdb or one of numerous frontends. Then you use the environment you already have - your own editor, shell, scripting language, version control, etc are all there. On Windows[*], few people develop like that because cmd.exe is an awful shell to work in, all this C:\Program Files\blah tends to get in the way of Unixy build tools like make, and command line editors etc aren't very good. Windows also makes it awkward to mix and match GUI tools (eg separate editor, compiler, debugger GUI apps). So instead people expect an IDE with its own editor, that does everything in house and lives in a single maximised window, and orchestrates the build pipeline. But then it starts bloating - the debugger gets brought in, then the programmer, then sometimes it starts growing its own idea of a version control client. And eventually you end up with something extremely complicated and somewhat flaky just to build a few kilobytes of code. Not to say that there aren't some useful features of IDEs - one thing is explicit library integration into the editor (so you get documentation and expansion as you type), another is special dialogues for configuration options in your particular chip (eg pin mapping or initial clock setup) rather than expecting you to configure all these things from code. The first is something that existing editors can do given sufficient information of the API, and the second is generally something you only do once per project. But for the basic edit-build-run-test cycle, the GUI seems mostly to get in the way. Theo [*] Powershell and WSL have been trying to improve this. But I've not seen any build flows that make much use of them, beyond simply taking Linux flows and running them in WSL.
Reply by ●December 3, 20212021-12-03
On 2021-12-03, Theo <theom+news@chiark.greenend.org.uk> wrote:> [*] Powershell and WSL have been trying to improve this. But I've not seen > any build flows that make much use of them, beyond simply taking Linux flows > and running them in WSL.I always had good luck using Cygwin and gnu "make" on Windows to run various Win32 .exe command line compilers (e.g. IAR). I (thankfully) haven't needed to do that for several years now... -- Grant
Reply by ●December 3, 20212021-12-03
Il 02/12/2021 12:46, pozz ha scritto:> When I download C source code (for example for Linux), most of the time > I need to use make (or autoconf). > > In embedded world (no Linux embedded), we use MCUs produced by a silicon > vendor that give you at least a ready-to-use IDE (Elipse based or Visual > Studio based or proprietary). Recently it give you a full set of > libraries, middlewares, tools to create a complex project from scratch > in a couple of minutes that is compatibile and buildable with its IDE. > > Ok, it's a good thing to start with a minimal effort and make some tests > on EVB and new chips. However I'm wondering if a good quality > commercial/industrial grade software is maintained under the IDE of the > silicon vendor or it is maintained with a Makefile (or similar). > > I'm asking this, because I just started to add some unit tests (to run > on the host machine) on one of my projects that is built under the IDE. > Without a Makefile is very difficult to add a series of tests: do I > create a different IDE project for each module test? > > Moreover, the build process of a project maintained under an IDE is > manual (click on a button). Most of the time there isn't the possibility > to build by a command line and when it is possible, it isn't the > "normal" way. > > Many times in the past I tried to write a Makefile for my projects, but > sincerely for me make tool is very criptic (tabs instead of spaces?). > Dependencies are a mess. > > Do you use IDE or Makefile? Is there a recent and much better > alternative to make (such as cmake or SCons)? >It's absurd how difficult is to create a Makefile for a simple project with the following tree: Makefile src/ file1.c module1/ file2.c module2/ file3.c target1/ Release/ src/ file1.o file1.d module1/ file2.o file2.d module2/ file3.o file3.d Debug/ src/ file1.o file1.d ... Just to create directories for output files (objects and dependencies) is a mess: precious rule, cheating make adding a dot after trailing slash, second expansion, order-only prerequisite!!! Dependencies must be created as a side effect of compilation with esoteric -M options for gcc. Is cmake simpler to configure?
