missing header file: itc_synopsis_bridge.h

[smccrossin]

I'm setting up NOS3 for the first time and am seeing this when I try to do the first make within VirtualBox:

[ 70%] Building C object apps/syn/fsw/CMakeFiles/syn.dir/src/syn_app.c.o
/home/jstar/Desktop/github-nos3/components/syn/fsw/src/syn_app.c:14:10: fatal error: itc_synopsis_bridge.h: No such file or directory
   14 | #include "itc_synopsis_bridge.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[7]: *** [apps/syn/fsw/CMakeFiles/syn.dir/build.make:76: apps/syn/fsw/CMakeFiles/syn.dir/src/syn_app.c.o] Error 1
make[6]: *** [CMakeFiles/Makefile2:6917: apps/syn/fsw/CMakeFiles/syn.dir/all] Error 2

I searched for this file. It does not appear anywhere in my clone of the repository. So I don't think this is an include path problem.

I see the problem both when using the dev branch (as instructed by the Wiki) and the main branch. I cloned the repository early this morning Pacific time, 10/18/2024. [Main branch was at commit 4d653f2a3defea391019176064173e12a0d674eb from 8/30/2024; notes say it's Release 1.7.1.]

I don't know if it's related, but the following warning, also having to do with the syn component, appeared earlier in the make output:

CMake Warning (dev) at /home/jstar/Desktop/github-nos3/components/syn/fsw/CMakeLists.txt:5 (add_subdirectory):
  The source directory

    /home/jstar/Desktop/github-nos3/components/syn/synopsis

  does not contain a CMakeLists.txt file.

  CMake does not support this case but it used to work accidentally and is
  being allowed for compatibility.

[smccrossin]

Other notes: I'm able to make config, sim, and gsw without problems. It's just fsw that's failing, due to the missing header file.

I'm pretty sure I followed the instructions in the Wiki. This is what I did: In host -- 1) Clone repository. 2) Do 'git submodule init' [no errors] 3) Do 'git submodule update' [no errors] In the VM -- 1) cd to the shared directory at ~/Desktop/github-nos3 2) Do 'make clean' [no errors] 3) Do 'make prep' [no errors] 4) Do 'make' [make of fsw fails due to missing header file]

After the initial failure with the dev branch, I was careful to close the VM, switch the repository to main in the host, reopen the VM, and run both 'make clean' and 'make prep' before trying another 'make'.

[smccrossin]

Figured it out. The syn submodule contains a submodule itself (synopsis), and it turns out that submodule init and update have to be run with a special option when submodules are nested: --recursive. Moreover, they need to be bundled (I think) since 'git submodule init' does not have a --recursive option. Long story short: 'git submodule update --init --recursive' does the trick.

It may be good to update the Wiki first time setup page (https://github.com/nasa/nos3/wiki/NOS3-Install,-Build,-Run-Quick-Start) with this change. There are a few other respects in which it's out of date. Since I just did the process and have it fresh in my mind, I'd be happy to help out with this if folks like.

[Isgaroth-the-Green]

Good morning.

You are right about git submodule update --init --recursive; that is how we always run and it should definitely be that way in the Wiki. When you mention other respects in which it is out of date, what do you mean?

We are always happy to have assistance from the community. In the specific case of the Wiki, however, you will probably not be able to make changes because of the way that it works (and the fact that it does not operate as a merge request). I would be happy to make them on your behalf, though.

[smccrossin]

Hi, thanks so much for helping me out with this. After my initial post, a friend directed me to the README, which does indeed have the git submodule update --init --recursive. I deleted my VM, uninstalled VirtualBox and Vagrant, then started over with the README directions and everything was great (except that the NOS time server is not launching -- I'll ask about that one separately). Anyhow if you compare the README to the Wiki page you can see a few differences. I'm wondering, would it make sense to replace the directions on the Wiki page with a link to the README so that the project only needs to update the install directions in one place?

[Isgaroth-the-Green]

My inclination is to leave things in both separate places; the directions for running everything do not change that much, and I think it would be somewhat more convenient for the user to not have to follow links to README files and such.