Why is JerryScript's structure so deep?

[IngwiePhoenix]

Hey!

For a project that I am working on, I need a scripting language that is familiar to developers - so I decided to go and try out JerryScript. But good lord, I had no idea... ^^;

I generated this command quickly by using the fish shell:

echo gcc (find jerry-core jerry-ext jerry-main jerry-port/default/include -type d -exec echo -n "-I{} " \;) (find jerry-core jerry-ext jerry-port -name "*.c" -exec echo -n "{} " \;) jerry-main/cli.c jerry-main/main-unix.c -o jerry | pbcopy

and manually appending the -D definition.

This command is big and I wonder: Why is JerryScript's structure so huge, and is there some kind of explanation on how to integrate JerryScript on one's own build system, what -D's it accepts and such?

I will need to add JerryScript into my own build tool, hence I tried to reproduce a full compilation "by hand" to learn how it is being built. And well, I learned that - and I am surprised I did not exceed the maximum number of arguments... ;)

Kind regards,
Ingwie

[dbatyai]

Hi!

I'd say the typical way of integrating JerryScript would be to treat it as a sub-project, and use either cmake or python to compile it, and link the created archives to your project.

Although looking at how you approach it, this might not be suitable for you, in that case you could take a look at the all-in-one feature implemented in #2790. This could be used to generate a much simpler file structure which you can then add to you build system.

If you're looking for compiler definitions, you could look at jerry-core/config.h, you can find most of them there, but for the rest you may need to look at what happens in jerry-core/CMakeList.txt:216-335.

Kind regards,
Daniel

[akosthekiss]

Hi,

Why is JerryScript's structure so huge

"Huge" is quite subjective. And you've just mentioned at #2858 that it's a "small source tree", actually. So, I go with your second assessment. :)

I am surprised I did not exceed the maximum number of arguments

Well, most of the length of the command line comes from the fact that you passed all source files to gcc in a single step. Projects with multiple source files are usually compiled file-by-file and then the objects are linked at the end. That makes the command line needed to compile the individual source files much shorter. JerryScript and its build system is no different [1]. If you try and build it with cmake, you'll see it [2].

[1] Actually, JerryScript has an "all-in-one" build option when all sources of the core library are built as part of a single compilation unit. It is achieved by creating a source file at build time that #includes all other source files. Look for "All-in-one build" in jerry-core/CMakeLists.txt for the gory details.

[2] There is a python wrapper around the cmake-based build system at tools/build.py . But the build system is still cmake-based after all.

I will need to add JerryScript into my own build tool

More details on this would be useful. Does that mean that you need to include all the sources and headers in your source tree and build everything by your build system? Or can you build external projects into object libraries? In the latter case, just integrate our cmake build into yours (in most build systems that should be doable). In the former case, well, just add all the .cs and .hs to your project.

what -D's it accepts

The python build wrapper (via its --help and --devhelp options) and cmake itself (via ccmake or cmake -i) do give information about the options our build system accepts. Those are not exactly the -D macro definitions that the C preprocessor accepts, of course, but quite close. If you really want to avoid the the project's build system, I think you'll have to take a look into the CMakeFiles, because those translate the -D cmake option definitions to -D preprocessor macro definitions.

And one extra note: the options that you can enable/disable via cmake options are those that tweak the engine's internals. Those options that enable/disable JS language features (or specify which standard version to support) are controlled by so-called profiles. More on that at jerry-core/profiles/README.md .

I hope that helps.

[IngwiePhoenix]

Hey @dbatyai !

Although looking at how you approach it, this might not be suitable for you, in that case you could take a look at the all-in-one feature implemented in #2790. This could be used to generate a much simpler file structure which you can then add to you build system.

This is indeed interesting! In fact, this might just be what I needed. I am not sure just yet, but thank you for pointing it out.

If you're looking for compiler definitions, you could look at jerry-core/config.h, you can find most of them there, but for the rest you may need to look at what happens in jerry-core/CMakeList.txt:216-335.

I will definitively do that. I already have given it a short glance, but I really need to read it throughly.

Thank you for your reply!

[IngwiePhoenix]

Hey @akosthekiss !

"Huge" is quite subjective. And you've just mentioned at #2858 that it's a "small source tree", actually. So, I go with your second assessment. :)

"Huge" might be the wrong word actually - and this is my fault :). I am not a native english speaker, so this sometimes happens. What I meant was to describe the depth of the source tree. Like, this:

$ gcc src/*.c -Isrc -o prog

VS.:

$ gcc -I include src/*.c ext/*.c -o prog

and so on. JerryScript's structure is so deep, that without some kind of script usage - be it by using a shell's globbing, expansion or tools like find - it is not possible to build right away.

I hope I was able to express myself a little better this time. :)

Well, most of the length of the command line comes from the fact that you passed all source files to gcc in a single step. Projects with multiple source files are usually compiled file-by-file and then the objects are linked at the end. That makes the command line needed to compile the individual source files much shorter. JerryScript and its build system is no different [1]. If you try and build it with cmake, you'll see it [2].

[1] Actually, JerryScript has an "all-in-one" build option when all sources of the core library are built as part of a single compilation unit. It is achieved by creating a source file at build time that #includes all other source files. Look for "All-in-one build" in jerry-core/CMakeLists.txt for the gory details.

[2] There is a python wrapper around the cmake-based build system at tools/build.py . But the build system is still cmake-based after all.

Yes, I am aware of that. In fact, I want to write a build tool ontop of JerryScript - so I am well aware :). But in order to practice and get to know JerryScript's source tree a little better, I just tried to compile it off a single command. In build scripts, it is obviously much better to go file-by-file and all that good stuff - but, for getting to know a source tree, I thought this might be a good first approach before throwing the bigger guns at it :)

More details on this would be useful. Does that mean that you need to include all the sources and headers in your source tree and build everything by your build system?

No - not exactly. I will use Git modules to "link" to JerryScript as a "dependency". Obviously Git modules aren't exactly meant for that, but can certainly be used for that.

Or can you build external projects into object libraries? In the latter case, just integrate our cmake build into yours (in most build systems that should be doable). In the former case, well, just add all the .cs and .hs to your project.

Ah, good to know :) But I probably should keep the folder structure in tact. Well, since I will use Git modules anyway, there is no need tow orry about that.

The python build wrapper (via its --help and --devhelp options) and cmake itself (via ccmake or cmake -i) do give information about the options our build system accepts. Those are not exactly the -D macro definitions that the C preprocessor accepts, of course, but quite close. If you really want to avoid the the project's build system, I think you'll have to take a look into the CMakeFiles, because those translate the -D cmake option definitions to -D preprocessor macro definitions.

Well I did mean the preprocessor definition -D switch. But since @dbatyai has already pointed me at the CMake file, I guess reading it is my best option here. Although I find CMake's syntax kinda gross, its luckily not that hard to spot preprocessor defines (luckily...).

And one extra note: the options that you can enable/disable via cmake options are those that tweak the engine's internals. Those options that enable/disable JS language features (or specify which standard version to support) are controlled by so-called profiles. More on that at jerry-core/profiles/README.md .

Oh! I totally did not see the profiles before. That is certainly good to know. Thanks for pointing this out.

Well, there is a lot I have to check out now. Thanks to you two guys for replying!

[akosthekiss]

The discussion has been inactive for almost almost two months, and the last line has a "Thanks" in it, so it seems like a question replied, issue solved. Closing.