Before that they are in the debug folder.
They can be used by adding the symbols folder to Visual Studio:
> Tools > Options > Debugging > Symbols
Or Visual Studio Code:
Using the "symbolSearchPath" variable in the launch configuration
https://code.visualstudio.com/docs/cpp/cpp-debug#_additional-symbols
The script explains how to generate the xcode project and will generate
a folder containing the project at the current working directory where
it has been used.
Add an XCodeGen project spec to generate an XCode project which will be
using autoconf and automake to build, as well as exposing the generated
artifacts to other XCode projects.
This will be generating the build artifacts inside the product build
directory from XCode, so `Clean build folder` will work as expected in
the editor, and use dynamic plugins to copy them towards the final
application for now.
This project allows testing VLC directly through the iosvlc.m test
driver, without building VLCKit nor VLC for iOS or another test
application, by directly using XCode to run it on the targetted
platform.
Exposing such project also allows debug symbols and debugguer with
breakpoint support to work automatically, even when using the artifacts
in another project.
The xcode.sh script is added as a wrapper script to handle the
specificities of XCode when calling external buildsystem, in particular
the multi-arch building for archiving application and packages.
The copy_plugins.sh is added as a build phase script so that application
can install the plugins matching the architecture being built. It
currently probably fails with cases where some plugins are not built for
every architecture of a platform since I haven't tested that yet. It is
also quite "dumb" and re-do everything from scratch for now.
The contribs were built from contrib/contrib-xxx but installed into
build/contrib/xxx-yy so removing the build folder led to the contrib
being unused since every .target files from contrib/contrib-xxx would
still exist.
The simulators are constrained to specific iOS and tvOS minimal version
and not respecting the constraint would lead to incorrect build and
linking failure.
Not sure how this should really be handled yet though, maybe the
build.sh script should get some parameter for that, or define the
targets depending on the SDK version.
Previously:
- $PATH was set incorrectly to wasm-emscripten/bin
which is supposed to be wasm-emscripten/build/bin
- $PATH was updated after making the tools
Hence,
- The tools would be rebuilt every time build script is run.
- The setting of PATH variable would do nothing anyway even
if it was correct, as correct PATH is going to be set by the
configure script later anyway.
This patch will repurpose the line to avoid rebuilding of already
built tools.
If a regular gcc toolchain is also in the path the gcc-ar/gcc-ranlib
variants will be used. We want to use the one coming with the mingw-llvm toolchain.
This reverts commit 6db5fb2b64.
The wasm script currently builds with --disable-sout. So rav1e (AV1 encoder) will never be used.
Once/if disable-sout is removed then it will be picked automatically.
The cross-compiled binaries are likely not going to be usable on the host and
should not be added to the PATH. They should never be used to be consistent
between native and cross-compiled builds.
It was added in the original build script: 5648ecad1a.
This is done in the other contribs. It helps figuring out what is built in one
place and also what is pulled as a dependency.
The last remaining build script not to do it is Android but there's a
pending patch: https://code.videolan.org/videolan/libvlcjni/-/merge_requests/88
Both `-emit-llvm` and a `.bc` output extension are needed to export
bitcode since emscripten 3.1.50[^1]. Otherwise a plain object file will
be created.
[^1] 94b36c04dd
Steve Lhomme
Claudio Cambra
Felix Paul Kühne
Alexandre Janniaux
Maxime Chapelet
Khalid Masum
Dave Nicolson
Pierre Lamot
Fatih Uzunoglu
Alaric Senat
Marvin Scholz