make the CLI support depending on system headers and libraries (include and lib search paths)

[Akuli]

On my system, @cImport(@cInclude("stdio.h")) works, but @cImport(@cInclude("gmp.h")) doesn't. gmp.h is in /usr/include/x86_64-linux-gnu, and stdio.h is in /usr/include. I'm running a simple test file with zig test filename.zig --library gmp --library c:

// run with:  zig test filename.zig --library gmp --library c
const gmp = @cImport(@cInclude("gmp.h"));

test "asdasd" {
    var num: gmp.mpz_t = undefined;
    gmp.mpz_init_set_ui(&num[0], 123);
    defer gmp.mpz_clear(&num[0]);
    _ = gmp.gmp_printf(c"'%Zd' should be '-123'\n", &num[0]);
}

This worked in 0.3.0+9c5852aa, but is broken in 0.3.0+0a8a7a57. On this system, zig is cloned to ~/sourcestuff/zig and built there, then bin and lib are copied to ~/zig/ (~/zig/bin is in $PATH).

[Akuli]

If I do @cInclude("/usr/include/x86_64-linux-gnu/gmp.h"), I get a different error: lld: error: unable to find library -lgmp. gmp is installed with apt.

akuli@Akuli-Desktop:~$ apt show libgmp3-dev 
Package: libgmp3-dev
Version: 2:6.1.2+dfsg-1
Priority: optional
Section: libdevel
Source: gmp
Maintainer: Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>
Installed-Size: 21,5 kB
Depends: libgmp-dev (= 2:6.1.2+dfsg-1)
Conflicts: libgmp10-dev (<< 2:5.0.1+dfsg-7)
Replaces: libgmp10-dev
Homepage: http://gmplib.org/
Tag: devel::lang:c, devel::library, field::mathematics, implemented-in::c,
 role::devel-lib, suite::gnu
Download-Size: 15,1 kB
APT-Sources: http://pkgmaster.devuan.org/merged ascii/main amd64 Packages
Description: Multiprecision arithmetic library developers tools

akuli@Akuli-Desktop:~$ 

[Akuli]

This works:

zig test filename.zig --library gmp --library c --library-path /usr/lib/x86_64-linux-gnu/ -isystem /usr/include/x86_64-linux-gnu/

I still liked the old behaviour where I didn't need to specify the paths verbosely

[andrewrk]

This is an important topic moving forward. I recognize that for some use cases, this is a step backwards in convenience. Whereas before, @cImport would automatically look in system-dependent locations, now, it will not access any system directories unless explicitly requested. Zig is moving towards system-independent builds, which is great for cross compiling, and for the upcoming package manager, but it's less convenient for depending on system-installed packages, as this issue notes.

However, depending on system headers and libraries is an important use case, as long as it's intentional.

Note: stdio.h works for you because your target is x86_64-linux-gnu, which is one of the targets that now has libc out-of-the-box. See #514

I see a few different directions this could take, and I'm not sure which one is best yet.

• Zig CLI could include system headers and libraries by default, and we could have a -nostdinc parameter, mirroring clang's, that disables this functionality.
• Keep Zig CLI status quo, and in order to depend on system headers and libraries, you would have to use a command line parameter --enable-system-search-paths (or something like that)
• Zig CLI would not have the ability to search system paths. That would fall onto the zig build system, and you would do something like const gmp = b.findSystemLibrary("gmp", "gmp.h"); exe.linkLibrary(gmp);.
• Maybe we could do the first bullet point, but zig build system always passes -nostdinc and so you'd have to do the previous bullet point within the zig build system.

[thejoshwolfe]

Assuming the zig package manager works well, then i think the third bullet is best; make it explicit when you're depending on specific system dependencies. And projects that want to be friendly to the zig package manager would be encouraged to never do that.

EDIT: i take it back. i don't think i understand the usecase for this. i need to do more research.

[Akuli]

Boooooo. How in the world is this better than the old behaviour? I don't see how having to hard-code the path of a header file that includes the architechture name is "system-independent builds".

I still have no idea how to figure out the correct command-line arguments from a build script anyway. If that's not possible from within a build.zig, I'll just create a build.sh or something.

[andrewrk]

@Akuli did you see the first bullet point? I'm pretty sure that's exactly what you want, no?

[Akuli]

Yes, but I don't understand how the change gives more "system-independent builds".

[andrewrk]

The thing that got harder to do (and is an open issue because I recognize that it is a problem) is depend on your system's gmp library. So the fact that you're getting an error for trying to do a system-dependent build makes it harder to do on accident. You're getting an error for the thing that is preventing your code from working on more systems.

This will make a lot more sense once we have a working package manager, but given that we don't have that yet, I think it probably does make sense to do the first bullet point for the 0.4.0 release. It doesn't make sense to deprecate the "old way" of doing things until the new way is available.

[Akuli]

Yes, the first bullet point would be nice.

[Akuli]

Can someone ELI5 how relying on the system's gmp.h is "system-dependent"? If I write something like "install GMP with your favorite package manager" to my README, I expect everyone to install it before attempting to compile my code. As far as I can tell, using the system's package manager is a very cross-platform way to install C libraries.