search

gtk-rs / gtk

DEPRECATED, use https://github.com/gtk-rs/gtk3-rs repository instead!
https://gtk-rs.org/
MIT License
1.24k stars 82 forks source link

WIP: test metadeps sys branch #1005

Closed gdesmott closed 4 years ago

gdesmott commented 4 years ago

Not meant to be merged, I just want to have the CI running.

gdesmott commented 4 years ago

@sdroege @GuillaumeGomez : this was a build test using my metadeps sys branch.

To my surprise all tests passed so I'm wondering what's the actual use case for all the current build.rs hacks: GTK_INCLUDE_DIR, GTK_LIB_DIR, windows specific paths, etc?

sdroege commented 4 years ago

Maybe they're not even required anymore and are just cargo culted for future generations. @EPashkin would know.

But as I said on IRC, we should really get rid of those hacks and instead set up the Windows CI environment correctly. Which might've happened by now (maybe msys2 fixed their packages...).

EPashkin commented 4 years ago

I tested on Windows with last msys2x64 and seems hardcode_shared_libs branches in good pkgconfig case now not needed (I not remember why it was added). But IMHO we still better have GTK_LIB_DIR and fallback. Not sure about GTK_INCLUDE_DIR

sdroege commented 4 years ago

But IMHO we still better have GTK_LIB_DIR and fallback. Not sure about GTK_INCLUDE_DIR

The fallback is provided by metadeps in this branch, which allows to override things in a generic way for each dependency so that people can continue to work around their broken environments.

EPashkin commented 4 years ago

The fallback is provided by metadeps in this branch, which allows to override things in a generic way for each dependency so that people can continue to work around their broken environments.

I don't see fallback not in sys branch not in https://github.com/gdesmott/metadeps/blob/master/src/lib.rs

gdesmott commented 4 years ago

It's all in my wip branch for now.

EPashkin commented 4 years ago

I missed that it have branch, but IMHO it still don't have "similar" failure case https://github.com/gdesmott/metadeps/blob/wip/src/lib.rs#L310

gdesmott commented 4 years ago

What do you mean? This feature is meant for crates building internally the underlying C library to statically link to it. That's not something we currently support in gtk-rs.

EPashkin commented 4 years ago

Yes, that why I say that you sys'es needed special fallback for this errors.

gdesmott commented 4 years ago

How so? metadeps will raise an error if user tries to use this feature as our sys don't implement a build closure.

EPashkin commented 4 years ago

How so? metadeps will raise an error if user tries to use this feature as our sys don't implement a build closure.

And pkgconfig error is lost and we can't find it by metadeps error.

gdesmott commented 4 years ago

But that only happens if user explicitly defined METADEPS_GTK_BUILD_INTERNAL=auto or always. The default value is never so metadeps will fail on pkg-config and report its error.

EPashkin commented 4 years ago

Sorry, I seems totally go to wrong direction. So we just need don't forget to add it in your sys'es.

sdroege commented 4 years ago

So we just need don't forget to add it in your sys'es.

Add what?

EPashkin commented 4 years ago

https://github.com/gtk-rs/sys/blob/master/gtk-sys/build.rs#L100-L106

sdroege commented 4 years ago

That's something for metadeps to take care of. The goal here is to move away from all these custom hacks that work differently for every crate.

Also the above part you linked shouldn't be done unconditionally as that regularly causes problems for users, especially on Windows. It needs to be something to opt-in for the user, which is already possible with metadeps by setting the correct libraries for the corresponding crate.

sdroege commented 4 years ago

This was merged