Re-thinking the build system (proposal)

[akosthekiss]

Foreword

I bear much love for autotools. However, I accept that JerryScript and several projects around it (e.g., IoT.js, libtuv) have decided to use cmake a long time ago. So, I wont propose to drop cmake for autotools. But still, I feel that the current build system needs a major revision.

(Still, should I be not the only one craving for autotools, do let me know :) )

Analysis

To me, cmake is/should be analogous to configure: I tell it whether I want cross compilation or not, whether I'd like to disable some features or not, whether I want a debug or a release build, or where to find some dependencies -- and then it creates a Makefile for me so that when I run make with the build or install targets, that variant of the project will be built for me which I requested at the time of configuration.

And this is where the current build system deviates from the conventions. The build directory is not set up to build exactly one configuration of the project but potentially several variants: right now, the same build directory can/must be used for debug and release builds, for full or compact profile versions, etc. After a make precommit, I have 10 jerry core lib variants, 2 jerry libc variants, 10 jerry libm variants, and 10 command line interpreter binaries in build/obj/linux! And because we have to differentiate between them, they have quite non-standard names, like libdebug-mem_stats.jerry-core.a, librelease.jerry-libc.linux.lib.a, librelease-mem_stress_test.jerry-libm.lib.a, or debug.linux.

This can seem to be easy for us developers because the current build system ensures that at every precommit we build and test all configurations and we don't forget anything. But it's not what "others" (i.e., users, packagers, embedders) are used to. Rather, after the configuration happened and the build command finished, they (but even I) would expect a build dir to contain, say, 3 libraries and 1 command line tool: libjerry-core.a, libjerry-libc.a, libjerry-libm.a, and jerry (or something like that).

Proposal

I suggest to rework the CMakeLists according to the above, i.e., one build dir should deal with (build) exactly one configuration of the project's libraries and tools.

I think we can still adapt the Makefile in the root directory in such a way that we keep building and testing everything that we used to build and test with the current build system.

Risks

• Although we can keep every configuration built and tested, libs and binaries may turn up not where they used to (e.g., not at build/bin/debug.linux/jerry), or the invocation of the build system may change. This can cause annoyance for developers.
• We have some users/embedders who are already relying on the current build system and resulting file names. (E.g., just have a look at https://github.com/Samsung/jerryscript/blob/master/targets/nuttx-stm32f4/Makefile.nuttx , once build finishes, libs are renamed and copied around.) They all will need to adapt.

This is a breaking change. However, I do believe that it is worth making.

[zherczeg]

The current system has an advantage: you can run a "make release.linux" and get a binary. If we go the configure/make direction we need two commands. I don't mind reworking the build system if we can keep this simplicity.

[LaszloLango]

@akiss77, I like your proposal. +1

[akosthekiss]

@zherczeg: My problem with the current approach is two-fold (at least):

• Actually, the Makefile in the root directory is just a wrapper. And it is hiding away the real(!) build system, which is already a cmake-based one. Which means, it is expected to be used in a cmake && make fashion.
• Actually, make release.linux builds 5(?) binaries! (full profile, compact profile, minimal compact profile, mem-stats, and I cannot recall the last one)

That being said, I do think that we can still keep scripts or Makefiles around that help testing all variants of the system (or just a single one, if that's needed).

As mentioned in the risks section, I do see that such a rework may cause inconvenience to developers in the short term. But let's try to minimize that.

[zherczeg]

Ok then. Feel free to work on this.

[akosthekiss]

I think we have successfully finished this recently. (Feel free to reopen if disagree.)