Re: importC and cmake
On Wednesday, 28 September 2022 at 05:29:41 UTC, Chris Piker wrote: `Xmake` is indeed simpler. `Xmake` is really nice!
Re: importC and cmake
On Wednesday, 7 September 2022 at 00:31:53 UTC, zjh wrote: `xmake` is simpler. Thanks for the recommendation. Was struggling with cmake for a dependent clib. Xmake is indeed simpler.
Re: Template function alias that leaves out the last type parameter
On Tuesday, 27 September 2022 at 23:18:06 UTC, Adam D Ruppe wrote: On Tuesday, 27 September 2022 at 22:39:52 UTC, torhu wrote: How would I achieve something like this, do I have to turn the aliases into functions? You can write it out long-form with two steps like this: Thank you, works like a charm!
Re: Template function alias that leaves out the last type parameter
On Tuesday, 27 September 2022 at 22:39:52 UTC, torhu wrote: How would I achieve something like this, do I have to turn the aliases into functions? You can write it out long-form with two steps like this: --- template _messageBox(string title, int style) { void _messageBox(T...)(T args) { import std.format; string s = format("%s", args); /* etc... */ } } alias _messageBox!("lol", 4) info; alias _messageBox!("Warning", 4) warning; alias _messageBox!("Error", 4) error; void main() { info(4, "ok"); } ---
Re: Template function alias that leaves out the last type parameter
On Tuesday, 27 September 2022 at 22:39:52 UTC, torhu wrote: How would I achieve something like this, do I have to turn the aliases into functions? ```d void _messageBox(string title, int style, T...)(T args) { string s = format(args); /* etc... */ } alias _messageBox!(APPNAME, SWT.ICON_INFORMATION) info; alias _messageBox!("Warning", SWT.ICON_WARNING) warning; alias _messageBox!("Error", SWT.ICON_ERROR) error; ``` I should mention that I am really looking for a Phobos 2 way of achieving what I currently do, which is this: ```d void _messageBox(string title, int style)(...) { char[] msg; void f(dchar c) { encode(msg, c); } doFormat(&f, _arguments, _argptr); messageBox(cast(string)msg, title, style); } ```
Template function alias that leaves out the last type parameter
How would I achieve something like this, do I have to turn the aliases into functions? ```d void _messageBox(string title, int style, T...)(T args) { string s = format(args); /* etc... */ } alias _messageBox!(APPNAME, SWT.ICON_INFORMATION) info; alias _messageBox!("Warning", SWT.ICON_WARNING) warning; alias _messageBox!("Error", SWT.ICON_ERROR) error; ```
Re: Is there a way to mark a dub package as linux only?
On 28/09/2022 7:18 AM, Alain De Vos wrote: Don't forget there is also BSD Should already be supported. Platform specific settings are supported through the use of field name suffixes. Suffixes are dash separated list of operating system/architecture/compiler identifiers, as defined in the D language reference, but converted to lower case. The order of these suffixes is os-architecture-compiler, where any of these parts can be left off. Additionally on Windows the architectures x86_omf and x86_mscoff can be used with dmd to differentiate between 32 bit object formats used with the --arch switch. Examples: https://dub.pm/package-format-json.html#build-settings
Re: Is there a way to mark a dub package as linux only?
Don't forget there is also BSD
Re: Is there a way to mark a dub package as linux only?
Alternatively we could just extend platforms to work in places other than configurations. https://dub.pm/package-format-json.html#configuration-settings
Re: Is there a way to mark a dub package as linux only?
On 9/26/22 4:57 PM, Christian Köstlin wrote: Or posix only? Or not windows? Kind regards, Christian We have specific directives based on os, I had an idea that you could say something like: ```json "dependencies-windows": { "not-available" : "*" } ``` But it still tries to find this package even on non-windows OSes, so that doesn't work. This still wouldn't prevent you from adding the dependency on your non-supported OS in the first place, but I'm not sure that's a good UX, since someone might add a dependency for a specific OS, even when not on that OS. You could possibly create little stub packages for all OSes to be excluded, like `exclude-os:windows`, and then you could add those dependencies to non-windows libraries. Yes, it would download those stubs once, but would fail to build on the "wrong" OS. I think your best bet is to version the whole library out, and let them read the static assert message from compiling against your library. -Steve
Re: Is there a way to mark a dub package as linux only?
On 27.09.22 13:07, Ahmet Sait wrote: On Monday, 26 September 2022 at 20:57:06 UTC, Christian Köstlin wrote: Or posix only? Or not windows? Kind regards, Christian Not necessarily a dub solution but you can do something like this: ```d version(Posix) { } else static assert(0, "Unsupported platform."); ``` This will result in a compiler error while targetting a non-posix platform. Thanks a lot ... but thats a little late for me :) as someone already might have added my library and was looking forward on using it.
Re: Is there a way to mark a dub package as linux only?
On Monday, 26 September 2022 at 20:57:06 UTC, Christian Köstlin wrote: Or posix only? Or not windows? Kind regards, Christian Not necessarily a dub solution but you can do something like this: ```d version(Posix) { } else static assert(0, "Unsupported platform."); ``` This will result in a compiler error while targetting a non-posix platform.