Cool! :D
I’m eager to see the PR!
Did you check that cmake already has some graphviz support?
I did
$ cmake —help
and I saw there is already a —graphviz option
…
--graphviz=[file] = Generate graphviz of dependencies, see
CMakeGraphVizOptions.cmake for more.
…
Is there a difference?
- how can we make the VM configuration step closer to your report
=> when we do cmake -B dir -S source
cmake does a configure step, where it looks for compile time and runtime dependencies, and it prints that to the stdout. We should be able to enhance it to have what you have in the report.
Another question is maybe to review the defaults of the current configuration?
Today I checked a bit the CMakeLists.txt and what would be nice is to split (or organize) the file because it's a bit of a bed sheet?
Yes, the reality is that we learnt a lot about CMake while making the CMake configuration of the VM.
It was difficult at the beginning because the nice documentation about CMake is a bit scarce.
So there are parts that are a bit rough and could be enhanced a lot.
Now we know a lot more, but our time is somewhere else...
I’d suggest starting with concrete and small steps.
Do some small PRs, they will pass easily :)
If you want we can do a fast call and do a code review and identify concrete things to do in this direction!
Some ideas are around
- using toolchain files,
- removing manual compiler options, let CMake do it’s thing
- check how to simplify the cygwin builds (that need path conversions…)
- dependency checks could also be done separately
- split the compilation of ffi support
- then also how plugins are build could be enhanced by a lot using what I drafted for the plugin compilation
For example, right now the VM build assumes that if you’re in *nix, you will apt-get your libs yourself.
However:
- that does not always work
- Pharo does not nicely report when a lib is missing/not found, so this makes people think “The VM does not work!"
I wonder what would be a better default configuration.
I wonder myself how do you discover the default configuration?
It really depends on what you mean by configuration!
One way is to look at the CMakeLists.txt.
In the first ~30/40 lines we have all options listed.
A quick google search tells that doing:
cmake -LAH -S source
or
cmake -LAH buildDirectory
prints all options with their default values and description.
So it seems it’s just a matter of doing a proper cmake configuration :)
> El 15 mar. 2023, a las 02:09, Hernán Morales <hernan-federico.morales@inria.fr> escribió:
>
>
>
> De: "Guille Polito" <guillermo.polito@inria.fr>
> I wonder:
>
> - how this can get to the mainstream VM
> => the graphviz cmake file is nice :)
>
> I just add a target to the CMakeLists.txt which you can check here (not PR yet):
>
> https://github.com/pharo-project/pharo-vm/compare/pharo-10...hernanmd:pharo-vm:add_graphviz_target?expand=1
>
> the idea is to configure normally and then launch the install with the target "graphviz"
>
> cmake --build build --target graphviz
Cool! :D
I’m eager to see the PR!
Did you check that cmake already has some graphviz support?
I did
$ cmake —help
and I saw there is already a —graphviz option
…
--graphviz=[file] = Generate graphviz of dependencies, see
CMakeGraphVizOptions.cmake for more.
…
Is there a difference?
>
> - how can we make the VM configuration step closer to your report
> => when we do `cmake -B dir -S source` cmake does a configure step, where it looks for compile time and runtime dependencies, and it prints that to the stdout. We should be able to enhance it to have what you have in the report.
>
> Another question is maybe to review the defaults of the current configuration?
>
> Today I checked a bit the CMakeLists.txt and what would be nice is to split (or organize) the file because it's a bit of a bed sheet?
Yes, the reality is that we learnt a lot about CMake ***while*** making the CMake configuration of the VM.
It was difficult at the beginning because the nice documentation about CMake is a bit scarce.
So there are parts that are a bit rough and could be enhanced a lot.
Now we know a lot more, but our time is somewhere else...
I’d suggest starting with concrete and small steps.
Do some small PRs, they will pass easily :)
If you want we can do a fast call and do a code review and identify concrete things to do in this direction!
Some ideas are around
- using toolchain files,
- removing manual compiler options, let CMake do it’s thing
- check how to simplify the cygwin builds (that need path conversions…)
- dependency checks could also be done separately
- split the compilation of ffi support
- then also how plugins are build could be enhanced by a lot using what I drafted for the plugin compilation
>
> For example, right now the VM build assumes that if you’re in *nix, you will apt-get your libs yourself.
> However:
> - that does not always work
> - Pharo does not nicely report when a lib is missing/not found, so this makes people think “The VM does not work!"
>
> I wonder what would be a better default configuration.
>
> I wonder myself how do you discover the default configuration?
It really depends on what you mean by configuration!
One way is to look at the CMakeLists.txt.
In the first ~30/40 lines we have all options listed.
A quick google search tells that doing:
cmake -LAH -S source
or
cmake -LAH buildDirectory
prints all options with their default values and description.
So it seems it’s just a matter of doing a proper cmake configuration :)
>
>
> Cheers,
>
> Hernán
>
>
> El 20 ene. 2023, a las 19:05, Hernán Morales <hernan-federico.morales@inria.fr <mailto:hernan-federico.morales@inria.fr>> escribió:
>
> Hi.
>
> I did a small package to ease VM compilation. Currently it generates:
>
> - A timestamped build directory for each usage.
> - A GraphViz with the Pharo VM dependency graph.
> - A compiler commands file (compile_commands.json) to help clangd find include paths in vscode (for this I'm experimenting a bit to see what automated/static checks could bring to the table).
> - A timestamped report file with lot of build information for example:
> - if we are in docker
> - ulimit
> - openssl, curl, wgetm git, etc versions
> - complete the tree of the build
>
> The repo: https://github.com/hernanmd/pharo-vm-builder <https://github.com/hernanmd/pharo-vm-builder>
>
> To use it:
>
> git clone https://github.com/hernanmd/pharo-vm-builder <https://github.com/hernanmd/pharo-vm-builder>
> cd pharo-vm-builder
> git clone https://github.com/pharo-project/pharo-vm.git <https://github.com/pharo-project/pharo-vm.git>
> ./pharo-vm-builder.sh
>
> Let me know any other suggestions,
>
> Cheers,
>
> Hernán
>
>
>