Re: Dub support was added to Meson
On Wednesday, 15 August 2018 at 09:31:48 UTC, Russel Winder wrote: That's the battle isn't it. Should the system that builds be the system that also manages the packages for the build (cf. Dub, Cargo, Go, Mason), or should the two be kept separate (cf. CMake, Meson, SCons, Make). The debate has been had on the D mailing lists a number of times and at great length. But in the end D, Rust, and Go are going with a single system for everything. This is obviously bad. Your distro has a package manager, you should use it, not create a separated language-specific one. If you are doing this locally, either but using the user's home of by installing to /usr/local, I don't think it's much of a problem. If you are implementing something like this at least do it in a way that the package managing feature is optional. I don't know if I'm being biased by being an Archlinux TU but from my perspective, it's not something we should do, at the very least globally. I am not sure how "dub describe" tells you which compiler is being used, it always says "compiler": "dmd" on my projects even though I only use ldc2 for build. Weirdly enough, I can reproduce. This was working when I wrote the patch. I've opened an issue in the upstream.
Re: Dub support was added to Meson
On Friday, 10 August 2018 at 14:38:10 UTC, Russel Winder wrote: First, you need to fetch and build the dependency. dub fetch vibe-d dub build vibe-d This feels a little unsatisfactory. Dub (and soon SCons I hope) builds handle getting the dependency as well as building it and thence linking the project to it. Meson both depends on the dub executable and yet isn't doing the getting, it is assuming already got. Yeah, Meson is a build system, not a package manager. This problem can be solved by simply creating a script that fetches and builds de dependencies. When creating a script, you might also want to compile the dependencies against the system's default D compiler. This way, you won't have any issues. I haven't finished reading the Meson source to find out which Dub built archive is used in the Meson build but if it is the one in ~/.dub/packages/-/ then stuff can go wrong since it is the result of the last build. In order to get the build with the specific compiler on the specific platform you have to delve into ~/.dub/packages/-//.dub/ and know the Dub naming strategy. For SCons I am having problems with this because of the extra stuff in the directory name. It uses 'dub describe' to find the files, this also allows us to check the compiler. Meson won't even let you try to compile the project if there's an compiler mismatch. I have been getting projects such as Unit-Threaded, DInotify, TinyEndian, and D_YAML to have Meson builds so as to create shared libraries prior to using pkg-config to handle D project being dependent on these libraries. It's working nicely (for me anyway) except Dub uses GitHub tags for versioning and Meson requires version numbers in the meson.build file. This duplication is getting quite annoying for all concerned. As is the Meson requirement to list all source files, rather than have a convention over configuration approach as Dub does – SCons has a different approach but still avoids explicit source lists. I can get round it with Meson, but I am informed it is naughty and should not be done. I mean, you can do this but as you said, it's not recommended. These builds create shared objects and allow for dynamic linking. Using Dub built archives means static linking. Unless Meson somehow manages to get shared objects out of the Dub build. Unless Dub can generate shared objects, having the dependencies build locally and creating pkg-config files actually seems a better way that accessing Dub builds. Dub is implemented this way for a reason. We really *shouldn't* use dynamic libraries, at least for now.
Re: Dub support was added to Meson
On Saturday, 4 August 2018 at 19:01:50 UTC, Russel Winder wrote: Great stuff. I have failed to date finishing Dub support in SCons, I shall have to put more effort in now. :-) The single biggest problem with D and Meson is that unit-threaded doesn't work with the way Meson works. Which is why I introduced the ProgramAllAtOnce builder into SCons. If there is a plan to try and make D/unit-threaded/Meson all work together, count me in as a tester at the very least. I'll keep an eye out for that. Maybe I'll try to implement something if my free time allows it :) PS.: Sorry for the grammar errors in the original post (mainly the "the Dub" :facepalm:), I rewrote some of the sentences and I didn't properly read the whole post again. Thanks, Filipe Laíns
Dub support was added to Meson
Hello,
Dub support was finally merged to the Meson's upstream.
For the ones that don't know, Meson[1] is a fast build system
that uses ninja[2] as a backend. Until now it was impossible to
use dependencies via the Dub and many many packages only
supported Dub. Now you can import dependencies that already exist
in Dub's local repo. You still need to fetch and build them
though.
First, you need to fetch and build the dependency.
dub fetch vibe-d
dub build vibe-d
Then you just need to specify Dub as the dependency method.
vibed_dep = dependency('vibe-d', method: 'dub')
Together with this, a 'dlang' module was also merged. You can use
it to automatically generate a dub.json file.
Here's an example.
dlang = import('dlang') # Import the module
# dlang.generate_dub_file(project-name,
path/to/where/to/install/the/dub/file,
# arguments... )
dlang.generate_dub_file(meson.project_name().to_lower(),
meson.source_root(),
authors: 'Foo',
description: 'Bar',
copyright: 'Copyright © 2018, Foo',
license: 'MIT',
sourceFiles: 'foobar.d',
targetType: 'executable',
dependencies: vibed_dep
)
If you have any issue with this, contact me at
la...@archlinux.org.
Thank you,
Filipe Laíns
[1] https://github.com/mesonbuild/meson
[2] https://github.com/ninja-build/ninja
Requesting some feedback for my Dub module for Meson
Hi, I am writing regarding my Dub module for Meson.
I wanted to check with the D community before my changes get
merged.
The module allows you to use dependencies provided by Dub in
Meson. It also allows you to automatically generate/update a
dub.json file for your Meson project.
Due Meson's policies, we can't download or build anything using
an external tool (Dub, in this case). My module only uses Dub as
a dependency resolver, kinda like pkgconfig. You will need to
build the dependencies before running meson.
Something to be aware when interfacing Dub and Meson is the
compiler. The libraries that we are linking should be built with
the same compiler Meson is using. This can be achieved as follows.
dub fetch vibe-d
dub build vibe-d compiler=ldc2
DC="ldc2" meson builddir
You can then use Dub to resolve the dependency as follows.
vibed_dep = dependency('vibe-d', method: 'dub')
You can generate/update a dub.json file for your project as
follows.
dub = import('dub')
dub.generate_dub_file(meson.project_name().to_lower(),
meson.source_root(),
authors: 'Filipe Laíns',
description: 'Test executable',
copyright: 'Copyright © 2018, Filipe Laíns',
license: 'MIT',
sourceFiles: 'test.d',
targetType: 'executable',
dependencies: vibed_dep
)
The only required arguments for generate_dub_file() are the
project name and the dub.json folder path.
All the other arguments can be passed as dictionaries.
key: 'value'
Currently, the module ignores configurations, subConfigurations,
and buildTypes because that would require unnecessary additional
code. You can configure that directly in dub.json. If you do
manually change dub.json, the configurations should be kept
unless you overwrite them in the meson config.
If you want to check the changes, you can take a look at the PR.
https://github.com/mesonbuild/meson/pull/3592
The questions I have to ask are:
- Does this fit your needs?
- Is there something I missed?
- Would you like me to add other features?
Thank you,
Filipe Laíns (FFY00)
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
Re: Arduino and D
On Saturday, 25 October 2014 at 22:55:12 UTC, Israel wrote: On Saturday, 25 October 2014 at 21:49:53 UTC, Ty Tower wrote: Has anybody tapped the massive Arduino programming explosion using D instead of C++ ? I got started on Arduino a few years back and it has taken the microprocessor popularity through the roof . Unfortunately you download the IDE (Integrated Development Environment) from Arduino.cc direct and then using a $3 development board with a 328p chip on it ,proceed to program the chip to do pretty much whatever you can think of including turning stuff on with your mobile from anywhere in the world and much much more . I wondered if someone could adapt it to D ? Well it is ARM so it should be possible. Actually, most arduinos use Atmel's chips so most of them are AVR. Apparently, there was some work done to port GDC to AVR [1]. I don't really know the usability of this but I suspect it's not much. If you want a board with similar size too small arduino like the pro/pro mini that has an ARM chip, you should have a look at Teensy[2]. Using D to program ARM chips shouldn't be that hard. [1] https://github.com/D-Programming-microD/GDC/tree/microD-4.9 [2] https://www.pjrc.com/teensy/
Re: Question over C++ to D conversion
On Tuesday, 15 May 2018 at 22:07:02 UTC, Filipe Laíns wrote: On Tuesday, 15 May 2018 at 21:00:25 UTC, Richard wrote: On Monday, 12 March 2018 at 03:42:41 UTC, jmh530 wrote: On Monday, 12 March 2018 at 02:48:17 UTC, Laeeth Isharc wrote: [snip] For conversion of C headers, watch this space. C first, C++ eventually. Might be a talk at Dconf on it. I think I saw a reference to this somewhere else. Sounds pretty darn cool. This might be it https://github.com/atilaneves/dpp I noticed it mentioned on the online DConf 2018 youtube video Are you aware of DStep? It has been working great for me. The only downside is that it doesn't do C++ at all :/ . https://github.com/jacob-carlborg/dstep Oh sorry, my mistake. I missed your link above.
Re: Question over C++ to D conversion
On Tuesday, 15 May 2018 at 21:00:25 UTC, Richard wrote: On Monday, 12 March 2018 at 03:42:41 UTC, jmh530 wrote: On Monday, 12 March 2018 at 02:48:17 UTC, Laeeth Isharc wrote: [snip] For conversion of C headers, watch this space. C first, C++ eventually. Might be a talk at Dconf on it. I think I saw a reference to this somewhere else. Sounds pretty darn cool. This might be it https://github.com/atilaneves/dpp I noticed it mentioned on the online DConf 2018 youtube video Are you aware of DStep? It has been working great for me. The only downside is that it doesn't do C++ at all :/ . https://github.com/jacob-carlborg/dstep
