3 ms·
└-- lib |-- cxx | └-- foo.cppm ---> this is a module interface (does `export module foo`) └-- libfoo.a Hm, .../lib/ normall
by boris 3y ago
└-- lib
|-- cxx
| └-- foo.cppm ---> this is a module interface (does `export module foo`)
└-- libfoo.a
Hm, .../lib/ normally contains architecture-specific files so I wonder what was the rationale behind installing architecture-independent source code (foo.cppm is a source file) there instead of something architecture-independent like .../include/?
- sph 3y agolib on Linux contains library files. On native languages, this means they contain native code, but not all library files are architecture-dependent. See Python files at /usr/lib/python<version> /usr/include on the other hand only is used for C and C++ header files. Modules are not header files.
- boris 3y ago> but not all library files are architecture-dependent. While this is definitely true, the presence in /usr/share/ of many files from library packages on my system (Debian) still suggests that architecture-independent files should not go into /usr/lib/. > See Python files at /usr/lib/python<version> Aren't the compiled (.pyc) files in there architecture-dependent (or could be; genuine question, I have no idea)? > /usr/include on the other hand only is used for C and C++ header files. Modules are not header files. Yes, but it doesn't follow they cannot be installed there if that location is the most suitable from the distribution packaging point of view.
- deleted 3y ago[deleted]
- bogwog 3y agoThat example isn't a linux file system, it's a Conan package. Conan packages are built for a single configuration/architecture, and only used when compiling your project. They live in a local Conan cache folder, and not installed on the system.