| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
There's no need to implement our own setting for RTTI, since Meson already
has a built-in setting. We just set the default to false, since that's
also the default for SpiderMonkey.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Based on looking at the git logs, add copyright notices to files which
were missing them, assuming the copyright belongs to people who made major
contributions to each file.
Some assumptions were made as to who to assign the copyright to, such as,
what copyright assignment did the contributor make in other files added in
the same commit? What email address did they use to make the commit? What
copyright assignment did they make in other commits using the same email
address?
|
| |
|
|
|
|
| |
This adds a SPDX-License-Identifier comment to all files that are part
of GJS, part of its unit tests, or auxiliary tools. (Except for some
files like the debugger scripts that don't support comments.)
|
| |
|
|
|
|
| |
After applying the workarounds in the sources, we can now restore support for
builds that are done using Visual Studio. Builds on Windows are now supported
both via Visual Studio and clang-cl.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since Spidermonkey 78, the headers shipped with it do not work on Visual Studio
builds without major and intrusive changes, so make the Meson build files work
for using CLang's `clang-cl` compiler, which is CLang that tries hard to
emulate the MSVC compiler and is the compiler that is being used to build
SpiderMonkey on Windows nowadays. As a result, we use Meson's
`cxx.get_argument_syntax() == 'msvc'` rather than `cxx.get_id() === 'msvc'`
(and so for the c compiler), so that we cover the case where we are using
`clang-cl`.
This also means that an error message will be displayed when one tries to use
the Visual Studio compiler when building GJS, and that we can start sharing
some of the compiler flags that is also being used for GCC (and other CLang)
builds. This also means that we can clean up the build files a little bit.
However, this will still require and use Microsoft's Windows SDK's headers and
libraries, so there are some Visual Studio-specific compiler flags that needs
to be kept, and the Cairo dependencies continue to be searched manually in
cases where the pkg-config files for them cannot be found.
Note that if the other dependencies of GJS were built with Visual Studio, they
do not need to be recompiled with `clang-cl` as long as they link to the same
C Runtime library DLL.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, we use the msvc_recommended_pragmas.h as we do in the GTK
stack, as well as in conjunction to disabling some other warnings,
as we do in the the NMake Makefiles, so that we cover more or less the
same items in MSVC builds.
Since there is no -Bsymbolic-functions equivilant in MSVC, we just skip
checking and using that as well.
Also, make sure that we pass in the additional flags that we need for
Visual Studio builds, as we did in the NMake Makefiles.
|
|
|
This adds a Meson build system which should be functionally equivalent
to the existing Autotools build system, but easier to deal with and
faster.
Equivalents:
./configure -> meson _build
make -j5 -> ninja -C _build
make install -> ninja -C _build install
make check -> meson test -C _build
It's also easy to run the tests under Valgrind or using the GC zeal
variables, by adding e.g. --setup=valgrind to the meson test command.
Dependencies (except SpiderMonkey) will be downloaded and built if not
present (or not new enough), using Meson's wrap system.
There were a small number of things the Autotools build did better. One
is export-symbols-regex which doesn't exist in Meson; we must write two
separate linker config files for GNU ld and macOS's linker, and I'm not
sure what happens in this case on Windows.
The other thing is merging the JS and C code coverage files
automatically. Since this isn't possible using Meson's b_coverage
option, we add a script, tools/run_coverage.sh, which generates a code
coverage report from start to finish. This is actually kind of better
than the old situation, since the script builds in a different build
tree, so you cannot accidentally leave coverage-instrumented build
artifacts sitting in your build tree.
|
