^ meson.build fmt static

[radonnachie]

20 lagging fixes...

Allowed me to cp the binary to a separate directory and run it there (just usage output).

[lacker]

After this change, is the fmt subproject still used? Or is this supposed to look for a fmt already on the system, or do some auto-downloading thing?

[radonnachie]

it's still using the fmt subproject it seems to me... I didn't update that to the wrap thingy Eli mentioned last time.

[radonnachie]

I think there is some inferred hierarchy mind... an existing fmt might be picked up in place of the subproject.. I'm not sure of the precedence here.

[lacker]

I checked out this branch and tried to build it, but it was unable to find the fmt dependency. Maybe this works for you because you have fmt installed globally?

lacker@freedom:~/ross/seticore$ meson setup build
The Meson build system
Version: 0.63.1
Source dir: /home/lacker/ross/seticore
Build dir: /home/lacker/ross/seticore/build
Build type: native build
Project name: seticore
Project version: undefined
C compiler for the host machine: cc (gcc 11.3.0 "cc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0")
C linker for the host machine: cc ld.bfd 2.38
C++ compiler for the host machine: c++ (gcc 11.3.0 "c++ (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0")
C++ linker for the host machine: c++ ld.bfd 2.38
Cuda compiler for the host machine: nvcc (nvcc 11.8.89
Build cuda_11.8.r11.8/compiler.31833905_0)
Cuda linker for the host machine: nvcc nvlink 11.8.89
Build cuda_11.8.r11.8/compiler.31833905_0
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Found CMake: /usr/bin/cmake (3.22.1)
Run-time dependency fmt found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency fmt

meson.build:19:0: ERROR: Subproject exists but has no meson.build file

A full log can be found at /home/lacker/ross/seticore/build/meson-logs/meson-log.txt

[eli-schwartz]

After this change, is the fmt subproject still used? Or is this supposed to look for a fmt already on the system, or do some auto-downloading thing?

It can look for one already on the system. When building self-contained binaries, I suggest configuring meson with --wrap-mode=forcefallback as that will force it to always use subprojects.

it's still using the fmt subproject it seems to me... I didn't update that to the wrap thingy Eli mentioned last time.

You need the wrap thingy to use the subproject.

[radonnachie]

I'd like to hard code any of the meson options as far as possible, couldn't see a way to do that with --wrap-mode=forcefallback. Thanks Eli.

[eli-schwartz]

Do you really need to guarantee the binaries can be copied to other computers? How does that currently work -- there's a dependency on hdf5, so it links to that and assumes it is externally installed.

[lacker]

It would be possible to change the deployment process to not copy things around, but it would be annoying, since deployment can only fully be tested when the radio telescope is operational, and we have a bunch of other stuff we want to test on the production system at the moment.

Works for me now. Let's give it a try.

[eli-schwartz]

Well, the wrap mode should be feasible to add into the deploy scripts that run meson setup, although it's also possible to set this in project(..., default_options: ['wrap_mode=forcefallback']).

I would tend to prefer doing it in the deploy scripts.

[lacker]

Ah, that explains why it's inconvenient for us to have non hard coded meson options, because we have no deploy scripts that do anything meson-related. I can imagine a more robust deployment system that did in fact work that way.

[lacker]

Failing in production again, sadly.

error while loading shared libraries: libfmt.so: cannot open shared object file: No such file or directory