Split example project into two

[mgeier]

One example is installed into the default location and it uses a single header file.

The other example is installed into a subdirectory and uses a bunch of more complicated features.

The idea is to test multiple combinations of options and to spot errors like #216.

This needs a fix to #216 before it can run successfully.

[codecov-commenter]

Codecov Report

Merging #217 (f2666cd) into master (d553e88) will decrease coverage by 4.51%. The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #217      +/-   ##
==========================================
- Coverage   83.27%   78.75%   -4.52%     
==========================================
  Files          12       12              
  Lines        1704     1704              
==========================================
- Hits         1419     1342      -77     
- Misses        285      362      +77     

Impacted Files	Coverage Δ
src/build.rs	72.86% <0.00%> (-9.60%)	:arrow_down:
src/bin/capi.rs	82.00% <0.00%> (+8.00%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update d553e88...f2666cd. Read the comment docs.

[mgeier]

The remaining CI error on macOS is caused by #216.

I don't know why the error on Windows/GNU is happening.

[lu-zero]

Please rebase it when you have time, I'll probably shuffle that around when I'll redo the workspace support on top of it.

[lu-zero]

Would be great to use always the pkg-config file so we'll avoid the problem of - vs _.

[mgeier]

Would be great to use always the pkg-config file so we'll avoid the problem of - vs _.

I'm intentionally using pkg-config in only one of the examples, because IMHO not using pkg-config is a very important use case as well.

[lu-zero]

Static linking is often broken if you do not bring in the dependencies by some means, dynamic linking normally works since the dependencies are encoded in the dylib itself.

pkg-config is the best solution to provide that information.

[mgeier]

Static linking is often broken if you do not bring in the dependencies by some means, dynamic linking normally works since the dependencies are encoded in the dylib itself.

I'm not against dynamic linking.

TBH, I don't know what is used in the example projects, I was assuming dynamic linking, but I don't actually know. I don't think this PR changes anything with regards to dynamic vs. static linking. If it does, please let me know.

pkg-config is the best solution to provide that information.

I'm not against using pkg-config at all. I just think that cargo-c should be able to install libraries that can be used without pkg-config as well (as long as they are not installed into a sub-directory).

So I think it makes very much sense to use pkg-config in one example and not use it in the other.

[lu-zero]

That use-case is unsupported because it is generally broken by design: either you have pkg-config telling you or you have to figure out by other means, such probing, the right paths and link lines.

[mgeier]

Since #216 has been fixed (thanks!), now there is only the Windows error left:

Without subdir (and without pkg-config):

cc     run_tests.c  -lexample_project -o run_tests
run_tests.c:1:10: fatal error: example_project.h: No such file or directory
    1 | #include <example_project.h>
      |          ^~~~~~~~~~~~~~~~~~~

With subdir (using pkg-config):

cc `pkg-config --cflags example_project_with_subdir`    run_tests.c  `pkg-config --libs example_project_with_subdir` -o run_tests
run_tests.c:1:10: fatal error: example_project_with_subdir/example_project_with_subdir.h: No such file or directory
    1 | #include <example_project_with_subdir/example_project_with_subdir.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Any ideas how to fix this?

[lu-zero]

Do not use #include <> but #include ""

[mgeier]

Do not use #include <> but #include ""

As mentioned above (https://github.com/lu-zero/cargo-c/pull/217#discussion_r684646568), I don't think this is the right thing to do (regardless whether it gets rid of the error or not).

I've just fixed the installation directory in f2666cd464262c8e025cf7fbc0e95f43b69cfd08 (it had been changed in 353e39014bbe9ecaa5a5a566581b5feae5df2020), and now it works again!

That use-case is unsupported because it is generally broken by design

I don't understand, can you please elaborate?

I've been using this for decades (on Linux) and it has been working fine for many different libraries. Libraries that have been installed to one of the default locations are automatically found by the compiler

And it works fine on the platforms tested in CI. The only place where it probably doesn't work is on MSVC, but I don't know if this even has a notion of "default library directories". Or does it?

[lu-zero]

Do not use #include <> but #include ""

As mentioned above (#217 (comment)), I don't think this is the right thing to do (regardless whether it gets rid of the error or not).

It is. In general you do not know which are the default search paths of the compiler you use. What you install is not part of the base system. There are even linux distributions that have a separate file-systems per-package.

I've just fixed the installation directory in f2666cd (it had been changed in 353e390), and now it works again!

It is brittle.

That use-case is unsupported because it is generally broken by design

I don't understand, can you please elaborate?

You do not know in general which are the compiler default search paths, they are implementation defined. On windows, as you noticed, they aren't conventionally commonly available ones.

I've been using this for decades (on Linux) and it has been working fine for many different libraries. Libraries that have been installed to one of the default locations are automatically found by the compiler.

This works by luck and conventions, but if, by chance, there is a file with the same name with a path with an higher priority you'd get surprising results.

[mgeier]

Do not use #include <> but #include ""

As mentioned above (#217 (comment)), I don't think this is the right thing to do (regardless whether it gets rid of the error or not).

It is. In general you do not know which are the default search paths of the compiler you use.

But there are some platforms with quite well established conventions.

And in case of doubt, a user can always specify additional search paths for headers (e.g. with -I).

What you install is not part of the base system.

I don't think it's relevant whether a header is part of the "base system" or not. Users can install headers e.g. in /usr/local/include and the #include mechanism works exactly the same.

There are even linux distributions that have a separate file-systems per-package.

Sure, maybe, but none of this has anything to do with <...> vs. "...".

According to the standard the behavior is indeed implementation defined, but https://en.cppreference.com/w/cpp/preprocessor/include#Notes gives us a few hints:

"Typical implementations search only standard include directories for syntax (1). [...] The standard include directories usually can be controlled by the user through compiler options. The intent of syntax (2) is to search for the files that are not controlled by the implementation. Typical implementations first search the directory where the current file resides then falls back to (1). "

That use-case is unsupported because it is generally broken by design

I don't understand, can you please elaborate?

You do not know in general which are the compiler default search paths, they are implementation defined. On windows, as you noticed, they aren't conventionally commonly available ones.

Yeah, but on Linux, macOS and MSYS2/MinGW64 there seem to be quite well established default paths.

I've been using this for decades (on Linux) and it has been working fine for many different libraries. Libraries that have been installed to one of the default locations are automatically found by the compiler.

This works by luck and conventions,

Conventions are great! I don't think there is much luck involved on Linux, on other systems I'm not sure.

but if, by chance, there is a file with the same name with a path with an higher priority you'd get surprising results.

No, I'm getting the expected results! That's the whole idea of multiple places with different priority.

The system package manager installs headers into /usr/include, but if I as a user want to compile my own version of the same library from sources, it typically gets installed into /usr/local/include, which comes earlier in the search path and it is used over the one from the package manager, just as I expected. This works really well!