Druntime: Changing the underlying C Standard Library
Hello, I'm writing an operating system in D for some exotic hardware. I understand the D runtime environment depends on a C stdlib being available (at compile time or run time?) As a consequence of the hardware, I need to use our own C std lib for the operating system. How can I set about directing the compiler (or run-time) to non-default implementation? Alternatively, I infer there's nothing breaking about replacing all of core.stdc with an implementation written in -betterC? Thanks, ST.
Using DLLs to extend an existing class
I'm developing a plugin system for a D program.
I have a complex class hierarchy which will be complied into our
executable, and I want
third parties to be able to further extend it with their own DLLs
- subject to implementing an API present in the most derived
class - which will be provided to the user as a auto generated
header (.di) file using "dmd -H [modules]"
For example, in our program:
---
class A
{
//Protected and public methods
}
class B : A
{
//Protected and public methods.
public string apiMethod()
{
return "Class B";
}
}
---
And in a typical "Dll to be' plugin:
---
import B; //Currently using a 'header' file generated with dmd -H
b.d;
mixin dllBoilerplate;
export class C : B
{
//Public (export?) API implimentation
override public string apiMethod()
{
return "Class C";
}
//Private methods
}
Currently, when I try to compile the plugin DLL, I get linker
errors that mangled symbol for apiMethod is not defined - These
are the symbols defined in the header (b.di) file, but are not
implemented: by definition intended to be part of the main
program, instead.
Can anyone explain how I should go about building the plugin - I
suspect it involved what I am and am not declaring 'export', but
I'm unable to find any material that puts light on my situation.
Thanks.
ST.
Re: CMake support for D
On Sunday, 3 January 2016 at 17:30:15 UTC, Dibyendu Majumdar wrote: Does CMake recognise D in the enable_language command? No. If not is there a workaround? I have a fork of CMake that adds D support here: https://github.com/trentforkert/cmake It's been a while since I published updates, but it should still work. If you encounter bugs please file them.
Re: What is the current status of D build systems?
On Friday, 31 July 2015 at 00:13:42 UTC, Yuxuan Shui wrote: I have come across cmake-d and a modified version of cmake (https://github.com/trentforkert/cmake). Oh hey, that's me! I haven't tested them yet, because neither of them is updated recently, and I don't know if I should invest time in them. I've got a handful of work-in-progress changes I've yet to push publicly, and even more I've yet to commit. (Yes, I have weird work habits.) So I want to know what is the current status of those build systems? I'm still around, and I fix bugs when they get in my way or someone else complains. Are they abandoned No. Neglected, but not abandoned. or still actively developed? If I can find the time (and the files, which hopefully survived a recent Linux distro-switch), I'll see about cleaning up and publishing the additional changes I have soon, and getting things on to a more recent version of CMake. As Steven Dwy said, I put the project on a bit of a hiatus while waiting for shared lib support to be ironed out (specifically, the behavior of `export`). Part of my unpublished changes includes a change that renders my previous concerns on that front solved regardless of what becomes of `export`. I would still like to be able to run tests for building shared libraries, and I won't even consider upstreaming until I can. Like I said though, I'll deal with bug reports if you file them. - Trent Forkert
Re: DDT 0.11.0 released
On Friday, 20 March 2015 at 14:36:51 UTC, Dicebot wrote: I wasn't referring to the vim vs IDE holy debate. I often use IDE myself but never use interal build systems tied to IDE - mostly for portability reasons. It is good to know that your project will always be built the same way - on local development box, in packaging script, on headless CI box. Which is one of the reasons I use CMake ^_^. It ensures the build button in your IDE behaves the same as make, regardless of which box the code is built on. Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much. It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work. .dproject is exactly dub.json As I said in my response to Bruno earlier, this still requires dub for things to work, which isn't an acceptable solution. A real .dproject would not require tools outside of Eclipse/DDT to function, and would preferably be similar to .project and .cproject. I don't really understand the part about putting paths to .project though That was a misunderstanding of Eclipse internals on my part. When the basic case of completing symbols from phobos worked, I just assumed that those include directories were being written to a portable place, since I hadn't done anything special for Eclipse project generation. how it can possibly put something that is language specific there? Include directories are not language specific, at least not in CMake.
Re: DDT 0.11.0 released
On Friday, 20 March 2015 at 15:52:18 UTC, Dicebot wrote: It is _supposed_ to be the same, but not necessarily is. Bugs in CMake generators are not impossible. Of course not, but I prefer a build system that works 99.99% of the time regardless of where it is used over a build system that can only be used on one machine or software stack. And I don't understand why it is not acceptable. * Because it is not guaranteed to be there. For instance, I don't have dub on my system * Because anybody not using dub should not be required to use dub. This is dlang, not dublang * Because it is at odds with C/C++ integration, which is an H1 priority * Because I just want to tell Eclipse about the project, there is no need to involve dub * Because the user said so dub is de-factor part of standard compiler toolchain for D. No it isn't. Neither is rdmd. Nor is make part of the standard compiler toolchain for C. When CDT uses make it does so *because it was told to*. Same with ninja. VisualStudio project generation doesn't use makefiles, because it is generating a VisualStudio project. And the fact that a whole bunch of abandoned single-module D libraries use dub is irrelevant when people like me, Manu, etc are working on larger, more complicated projects and say (repeatedly!!) that dub doesn't meet our needs. It is developed as D-Programming-Language organization project and planned for eventual distribution with compiler. rdmd is already distributed with dmd. Is it now a required part of the build process for all projects? VisualD is also developed under D-Programming-Language. Is it now required as well? Why isn't DDT using a .visualdproj? Saying that is unacceptable as dependency is similar to saying that Phobos is unacceptable as dependency. I'm not saying Phobos is unacceptable, but there are those that do. However, phobos is a library, not a build tool. Apples, oranges, etc. Include directories are not language specific, at least not in CMake. Sounds like design mistake to me. There is nothing similar between include directories in C and import paths in D. It's a list of directories. Sure, the compilers might do different things with the directories, but I've never encountered any harm from there just being a single list of directories to look for includes/imports in. Even within D -J paths and -I paths need to be treated differently. My fork handles -J paths separately from -I paths: include_directories(foo) # -Ifoo include_directories(TEXT bar) # -Jbar Similarly, CMake also handles regular vs system include paths for C/C++ compilers: include_directories(SYSTEM baz) # -isystem baz However, D doesn't have a -isystem, so SYSTEM is effectively ignored when producing the flags for a D compiler.
Re: DDT 0.11.0 released
On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote: I call dub from makefile rules and feel pretty comfortable about such pattern (apart from being not-so-portable compared to raw dub). And building anything via IDE is just asking for trouble :) I use Vim myself, but I think people who use IDEs would like to, well, use IDEs. Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much. It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work.
Re: DDT 0.11.0 released
On Thursday, 19 March 2015 at 15:14:09 UTC, Bruno Medeiros wrote: On 19/03/2015 14:45, Trent Forkert wrote: It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work. DDT does support a .dproject ... it's called dub.json ! ;) I'm dead serious here though. Why would I invent my own file format to describe source folders and include/imports paths when dub.json does that already?? 1. I don't consider an XML configuration to be your own file format 2. For the very reason that started this entire conversation. Not everybody *wants* to use dub. Not everybody *can* use dub. So it doesn't make sense for DDT to force dub. It would be silly to use anything else. VisualD has done pretty well for itself. If you absolutely don't want to use DUB to build things, there are ways to disable the DUB builder, as mentioned before in this thread, and this way you'll use dub.json merely to describe the import path structure of the D project. This still requires dub for things to work, which isn't an acceptable solution. Using XML the way CDT does also allows something else: GUI configuration. Users could then adjust build parameters via a GUI the way IDE users would expect to be able to, instead of editing a configuration file for a tool they aren't even using.
Re: DDT 0.11.0 released
On Wednesday, 18 March 2015 at 21:49:17 UTC, Bruno Medeiros wrote: Why is it insufficient? You don't have to use DUB to the exclusion of everything else. Isn't the use of the preGenerateCommands (http://code.dlang.org/package-format#build-settings) enough to call these other build systems you use? You're joking, right? The only sensible way to use multiple languages in the same project is to use the same build system for them. Anything else is way too fragile and hackish. Arbitrary, contrived example (though not entirely unrealistic): * a C(++) executable needs a static D library * Said D library in turn uses a C(++) library * All three of these are built as components of the same project So now I need a weird tangled mess of build systems calling each other back and forth. Dub really doesn't pull its weight here.
Re: DDT 0.11.0 released
On Wednesday, 18 March 2015 at 21:12:11 UTC, Bruno Medeiros wrote: What kind of Eclipse projects does it generate? CDT. Anything else would prevent it from supporting multi-language projects, and thus turn it into yet another crappy monolingual NIHS tool, and thus useless for me (and Manu). If it generates CDT projects, it's not really much help as CDT doesn't understand D (duh), Nor does it need to. The project builds with either Make or Ninja, and Eclipse doesn't even care that it is building D code, and will build successfully even if you don't have DDT installed. and DDT doesn't work with CDT projects (also duh). Not sure what you mean by that. Installing DDT allows Eclipse to see *.d files (in any project, DDT, CDT or otherwise) as D files that will be opened in Eclipse's editor with syntax highlighting, completion, etc. Without DDT, Eclipse opens D files in an external editor. I just double checked, this all still works as I was expecting it to.
Re: DDT 0.11.0 released
On Tuesday, 17 March 2015 at 23:54:06 UTC, Manu wrote: On 17 March 2015 at 06:00, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 06/03/2015 17:37, Bruno Medeiros wrote: A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) A new release fixing a critical regression is out: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.1 -- Bruno Medeiros https://twitter.com/brunodomedeiros I just checked out DDT, and I noticed it seems to use DUB... _ Why this marriage? I was really hoping it would be a lot more like CDT (ie, raw and flexible). In the project configuration I just see the one DUB Options box. The comprehensive suite of build options CDT presents would be much nicer. DUB is insufficient for any of my projects, and sadly, that makes DDT insufficient for my projects too :( The problem with DUB is it's self-contained. My projects involve cross-language interaction, and the build environments can be complex. DUB can't express this. I also couldn't launch GDB and debug the example 'hello world' app under Windows. Are there more steps to make this work? Unless something has changed recently, it shouldn't require dub. Last time I checked, my CMake work[1] could still generate projects for Eclipse from a D codebase, using Makefiles or Ninja. Not that that helps if you are creating a project from an Eclipse Wizard, which I haven't done in a long time. [1] https://github.com/trentforkert/cmake
Re: ICU D Wrapper
On Saturday, 13 December 2014 at 15:44:59 UTC, Sean Kelly wrote: On Friday, 12 December 2014 at 17:57:41 UTC, Trent Forkert wrote: I've looked into writing a binding for ICU recently, but ultimately decided to abandon that idea in favor of writing a replacement for it in D. Wow... really? You're actually going to write transcoders for all available encodings? Plus the conversion and parsing tools, plus expand our calendar functionality to handle the things it doesn't do now, plus... I mean I'd love it, but the scope of the project can be measured in tens of man-years. Running down the icu4c API listing: * Basic Types and Constants - only as needed * Strings and character iteration - Just use D strings, std.string * Unicode character properties and names - I think std.uni handles this * Sets of Unicode Code Points and Strings - ditto * Codepage conversion - ignoring, at least for now. See below. * Unicode text compression - again, I think std.uni handles this * Locales - yes * Resource Bundles - will offer equivalent functionality, just not identical * Normalization - std.uni * Calendars - see below * Date and time formatting - yes * Message formatting - yes * Number formatting / spell-out - yes * Transliteration - yes, but may be delayed until after initial release * Bidirectional Algorithm - not at first, is this in std.uni? * Arabic shaping - not at first, is this in std.uni? * Collation - I'm delaying this until after the initial release to get it out faster * String searching - depends on Collation * Index characters - depends on Collation * Text Boundary analysis - depends on Collation * Regular Expression - use std.regex * StringPrep - not initially, is this in std.uni? * IDNA - not initially, is this in Phobos? * Identifier spoofing and confusability - not initially * Layout engine - delayed, looks like ICU is removing this and pointing to another library * Universal Time Scale - see below * ICU I/O - use phobos There are very few things above that are not possible to generate from CLDR data. Of those, most are RFC-defined algorithms, several of which I believe are already part of Phobos. If I add codepage conversion, it will likely be in terms of iconv on POSIX and MultiByteToWideChar and friends on Windows. Alternatively, I could borrow the IBM CDRA/UCM data the way I'm getting almost everything else from CLDR data. Support of other calendar systems is up in the air at the moment. I had thought CLDR contained what I needed, but it looks like it might not. It has locale-specific formatting and display info for calendars, and mappings to when other calendar's eras begin in terms of the Gregorian calendar, but I don't see further breakdown of information. So, initially it looks like I'll only be supporting Gregorian calendar, but I may add the others in the future. It is a lot of work, yes, but the Unicode Consortium already does a significant chunk of it with CLDR. - Trent
Re: ICU D Wrapper
On Friday, 12 December 2014 at 16:51:43 UTC, Jake wrote: I'm not sure if anyone has noticed, but the D wrapper for C's ICU library is far from working it seems. mango.icu is its technical name. I've read articles on the forum about how excited people were to get ICU usable in D, but whoever made mango.icu hasn't made any updates on it or even documented it online. I'm just letting you all know about this. D seems to already have a bunch of ICU's functionality though, so maybe the wrapper died on purpose. I really just wanted to use its time zone and date features since std.datetime doesn't make it very easy to use the TZ database on Windows. I've looked into writing a binding for ICU recently, but ultimately decided to abandon that idea in favor of writing a replacement for it in D. The reasons for this are: * ICU breaks its ABI with every release, meaning a D binding would only work for one version of ICU, and need pragma(mangle) to have a hope of easy updating. Alternatively, what mango.icu seems to have done is load ICU at runtime in order to figure out what library to bind * ICU's data and APIs use UTF-16. I'd rather everything be UTF-8. * ICU's API is incredibly inconvenient for (if not impossible to access from) D. For example, some of the functionality requires binding C++ classes that use multiple inheritance * A decent chunk (though not all) of ICU is actually generated from CLDR, meaning I can do the same It looks to me like mango.icu hasn't updated since ICU v38 (it is up to v54 now), and made extensive use of wrappers in order to hide the C-API nastiness. It also doesn't support any of the functionality that requires C++. Binding ICU would be very nice, but this is one of the few cases I actually think we'd be better off rolling our own. I'm still a little ways off from having my work ready for public release, but I've been making good progress recently. If you can point out what ICU API you need, I'll make sure to included equivalent API in my library. - Trent
Re: Need help deciphering posix.mak
On Thursday, 4 December 2014 at 19:52:12 UTC, Dmitry Olshansky wrote: 04-Dec-2014 18:32, Dicebot пишет: Please no additional 3d-party dependencies for D core tool stack. What are current 3rd-party deps? Dependency on DMC make and compiler is already there, GNU make is not installed by default on FreeBSD. What would you suggest we do? Do what many large open source projects do: support multiple build systems. There is no reason that the addition of SCons/CMake build files to DMD would require the removal of the existing makefiles. It just means somebody has to do a little maintenance when source files are added/removed/renamed. - Trent
Re: SCons and D
On Sun, Sep 7, 2014 at 1:42 PM, David Nadlinger via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 7 September 2014 at 17:36:35 UTC, Trent Forkert via Digitalmars-d wrote: The support for D in CMake is currently very minimal. Various groups (including LDC) have partial solutions that work to a certain extent. That's a very kind way to put it. ;) I have seen far worse CMake configs. You deserve the kindness. As you certainly know (but others might not), we currently just invoke LDC as a custom command for building the runtime libraries, without any proper language support at all. This shows that CMake is flexible enough to handle atypical use cases like that, but I'm looking forward to your work for proper language support (compiler detection, …). If I remember correctly, Ben Boeckel from Kitware was also looking into adding D support to CMake a while back. How does your project relate to his? Ben's work was originally much more limited than mine. Once he found out about my work (read: once I pushed it to a public repo), he started helping me when time allows. I feel I should probably mention that his interest in D is (IIRC) as a Fedora contributor, updating old, abandoned D1 projects to D2, not in any official Kitware capacity. Cheers, David - Trent
Re: SCons and D
On Sun, Sep 7, 2014 at 5:31 AM, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: I realize that Dub is now the one true build system for D code, and indeed I will be using it for a couple of hobby projects. However we need to give people a way of moving from their current code bases to incorporating D: we need to give C, C++ and Fortran projects an easy transition to incorporating some D and then increasing their percentage of D as they see how much better it is than C, C++, Fortran. This means support for D in SCons and CMake – people using Make are on their own ;-) More than that, these systems need to be available for D users who need/want to use third party code that isn't in D. Dub can't (and in my opinion shouldn't) facilitate that. I am not really a CMake user (apart from compiling LDC), but I understand there is some support for integrating D into builds. Effort on this needs to be made very public and given lots of airplay. Ditto for SCons D support of course. The support for D in CMake is currently very minimal. Various groups (including LDC) have partial solutions that work to a certain extent. However, they miss out on a handful of CMake features. I have a project ( https://github.com/trentforkert/cmake) aiming to implement proper, full support, but there is still work to be done before it is even proposed for inclusion upstream. With SCons I have reworked what was in SCons to something more useful, and that is now in the distribution. However, it is in need of a lot more work. In particular: a. It needs someone who is a Windows user to be involved in sorting out the Windows side of things. b. It would be good if there was an everyday OSX user involved, whilst I have OSX I do not use it except occasionally. I am happy doing all the Python coding and pull requests etc, but I clearly need WIndows and OSX (and Linux, OpenBSD, FreeBSD, Solaris,…) people using my SCons branch to work with the D tooling to tell me what breaks and how to fix it. While my triple-booted MBP somewhat lessens my desire for OSX and Windows assistance, it would also benefit me. FWIW, I'll try to remember to grab SCons and test it out a bit next time I find myself in OSX or Windows. The problem of the moment is ensuring SCons D tools (there are three, dmd, gdc, ldc) are ready for all the dynamic linking stuff that is easing its way into D. Getting this right strikes me as a Good Thing™ for increased use of D: the main aim here is to ensure people with mixed language projects do not get hassles from the D side of things! -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder - Trent
Re: CMake for D
On Friday, 9 May 2014 at 21:11:54 UTC, Chris Piker wrote: On Monday, 24 March 2014 at 23:55:14 UTC, Dragos Carp wrote: I moved cmaked2 to github [1], updated and simplified the usage a little (system cmake patch not necessary anymore). You can give it a try. Dub registry support is also on the way. Dragos What is the best way to specify a mixin include directory for dmd under CMake? I can arbitarily add a -J option to the compiler flags but should the cmake-d module include a variable that should be set? -- Chris The way I've tackled that in my (still work-in-progress) CMake fork[1] is to add an `include_directories(TEXT ...)` signature. Unfortunately, you'll need to build my CMake from source, though that isn't difficult. Also, while I am hopeful about getting my changes merged upstream, there is no guarantee of that, so proceed with caution. Do note that my CMake work is independent of CMakeD2 and its forks. See my project wiki for more info. - Trent [1] https://github.com/trentforkert/cmake
Re: Distributing implib?
On Sunday, 27 April 2014 at 17:53:18 UTC, Jeremy DeHaan wrote: Hi all, I am doing some updates to the C back end of my binding, and I wanted to know what it would entail to be able to distribute implib along with my CMake things. I was just thinking that it would be nice to automatically produce .lib files when it builds 32bit libs on Windows systems. According to the license it comes with, I would need to obtain a redistribution license for this. Anyone else had any experience with that? Thanks much! Jeremy Nick already answered your question, but I have another suggestion for you. Set things up to look for implib (or perhaps coffimplib[1]), and complain if CMake can't find it. This tool should be part of the user's tools and environment, not part of your project. This may be my Linux bias talking, but I would tend to not want to ship binaries as part of my source. The good thing about CMake is that it can help you deal with your dependencies in a sane way. - Trent [1]ftp://ftp.digitalmars.com/coffimplib.zip
Re: CMake with D support early snapshot
On Tuesday, 1 April 2014 at 12:46:54 UTC, w0rp wrote:
This is all very interesting. I have two questions.
1. Do you plan to get this merged back into CMake proper?
Ideally, yes. But things are still in early stages, and that is
up to people who aren't me. Perhaps Ben can shed light on if
Kitware wants something like this upstream. However, I
effectively need CMake for a personal project, so I'll continue
maintaining this even if Kitware refuses an upstream merge. Once
things stabilize a bit more, I'll keep up-to-date binaries
published, too.
2. Could I use it to handle my weird build process?
At the moment I am working on something which requires
a strange build process, and I have been struggling to
implement it with existing build tools. First it needs to
compile and run a D program, which generates .d and .cpp files.
Then,
it needs to take all of those D and C++ sources and build one
library
out of them. This all works, I just need to get a build tool
that
does it all in one 'make' command or similar.
Yep, that sort of thing works:
CMakeLists.txt:
cmake_minimum_required(VERSION 3.0)
project(example D)
add_executable(codegen codegen.d)
add_custom_command(
OUTPUT generated.d
COMMAND codegen
)
add_library(generated generated.d)
codegen.d:
import std.file;
void main()
{
generated.d.write(q{
int myfunc()
{
return 42;
}
});
}
Then, to use CMake to generate Makefiles (or various other build
systems) and build:
mkdir ../path/to/builddir
cd ../path/to/builddir
cmake ../path/to/sourcedir
make -j4
Luckily for you, an old pet project of mine does something
similar to what you describe. I intend on reviving it in the near
future, and moving from a hacky shell script build system to a
CMake one. So, if something breaks, I'll be sure to fix it.
Be warned, however, that this project is still subject to
significant changes. For instance, I'm in the process of
replacing include_text_directories with
include_directories(TEXT), and thus improving the way -J flags
are managed. I'm sure other things will come up and need changed
as we encounter bugs.
- Trent
Re: CMake with D support early snapshot
On Tuesday, 1 April 2014 at 20:11:03 UTC, Meta wrote: Is this ready to be posted to HN/Reddit, or still no-go? I'm going to have to say no. A couple of major problems off the top of my head: 1. I've recently had to shrink the fully supported compilers list to DMD master and GDC 2.064 or greater, owing to a need for the compiler to handle shared libs passed directly to it and the -deps flag, respectively. LDC will be back on the list pending it gaining support for those things. 2. The major use case of mixing C/C++/D code is still fundamentally broken with Win32 DMD because of Optlink problems my poor Linux brain has yet to sort out. This is even more problematic, since the needed GDC version doesn't work on (or at least doesn't have a build for) Windows. 3. I'm still worried about creating confusion around CMake's pending 3.0 release. I want it to be as friction-less as possible for C/C++ CMake users to swap out their CMake install, add a D compiler, and start using D alongside C/C++ in their projects. Right now, such an effort would most likely be met with frustration pretty quickly. That frustration will end up aimed at D, even if it should be aimed at my work on this project. That won't benefit anybody. I've got a list of things in my head I want to be fixed/supported before publishing this too far and wide. I'll work on moving those from my head to the bug tracker tonight, so I don't forget about them. - Trent
Re: CMake with D support early snapshot
On Wednesday, 2 April 2014 at 03:34:14 UTC, Ben Boeckel wrote: However, I would like to get this to the CMake list sometime soon (within a month?) for feedback before too many start using it externally (especially since getting it on the radar for 3.1 would be nice). I can probably manage that. I'd also rather it go through CMake vetting before HN/reddit vetting, as I feel like the former would be a lot more productive than the latter. For example, it seems that there are new signatures that need vetting (include_directories(TEXT)), some new INTERFACE properties which need plumbed (text include directories at least, possibly DDoc stuff?), My understanding of INTERFACE properties is that they are used when dealing with importing/exporting targets. If this is the case, I'm not sure of a case when text includes would need to be provided through this. Text imports work at compile time, literally putting a string of the contents of the specified file where the import() was. and other minor things (cmDependsD not working for older compilers last I looked, Yeah, I'm not sure there's much I can do about that. I have to choose between scanning textually imported files as dependencies (which they are) or supporting older compilers. Granted, the Ninja dependency resolution doesn't register text imports, since I have to specify the filename in the arguments. -deps DEPFILE could work, but we would have to ensure that it comes last on the command line. -deps=DEPFILE doesn't output all the same information as -deps DEPFILE. Same holds for GDC and LDC equivalents. - Trent
Re: CMake with D support early snapshot
FWIW, I just pushed my implementation of cmDependsD[1], and found dmd-style deps much nicer to work with. I used the =2.064 ability to do dmd -c -o- -deps foo.d since that also contains file imports, which are technically dependencies. I missed when/if this was discussed on the list, but it seems that form of dependency output at least is intended to stay, even if it forces us to drop support for older compiler versions. - Trent [1]https://github.com/trentforkert/cmake/commit/bbaa6b1f82d6c55154a95d1995007e408c31103e
Re: CMake with D support early snapshot
On Wednesday, 26 March 2014 at 06:17:57 UTC, Ben Boeckel wrote: On Tue, Mar 25, 2014 at 14:12:45 -0400, Ben Boeckel wrote: I'll try it out when I get a chance. I've pushed some fixes to my CMake fork to work with GDC on Linux. I've also fixed up some things I saw and opened a bug on your fork (which isn't linked with Kitware/CMake, so PRs are unavailable…an unfortunate GitHub limitation; I've contacted support about this). I now have it working for a dummy project. I've also commented on the branch as a whole on that issue as well. --Ben As I told Ben on Github, I didn't realize CMake had a github mirror. So, I waved my magic wand and made trentforkert/cmake a github fork of Kitware/CMake so that PRs should work now. The original (non-github-fork) repo is now preserved at trentforkert/cmake_old, just in case we need it for something. - Trent
Re: CMake with D support early snapshot
I have a quandary you might be able to help with, Ben.
I've been working on moving dependency resolution things to
cmDependsD.cxx, and I've got it mostly working.
However, if we have gdc produce make-style dependencies (which
will still require processing to get CMake to be happy), that
requires me to put a special case in the C++ that I'd rather not
have.
The way I see it, there are three possibilities here:
1. Keep gdc producing make-style deps, and deal with that as
needed.
2. Have gdc produce dmd-style deps, and let the patched Ninja you
mentioned use that.
3. Have a separate flag registered for the two different styles
of dependencies.
I'm quite partial to number 3, as I could then use that to check
which flags are defined for which style is supported, and act
accordingly. I prefer that to hardcoding gdc does this. Anything
else does this other thing.
It should be noted that (AFAICT), the Ninja generator is the only
thing that even considers ${CMAKE_DEPFILE_FLAGS_lang}. All the
Makefile generators (basically everything but Ninja, VS, and
possibly XCode) use the cmDepends system.
Thoughts?
- Trent
Re: CMake with D support early snapshot
On Wednesday, 26 March 2014 at 23:17:31 UTC, Ben Boeckel wrote: What about: 4. Add depfile support to Makefile generators. That's basically what I'm doing, though only in the context of D. cmDependsD::WriteDependencies() gets called for every D object, and has the D compiler produce a dmd-style depfile of the relevant sources. It then scans each of the foo (.../foo.d) : public : object (.../object.di) lines, pulling the filepaths from the () to construct the file depends.make in the correct CMakeFiles/target.dir, which contains a list of lines like: .../foo.d.o: .../foo.d .../foo.d.o: .../object.di Yeah, seems so. If we could get rid of the cmDepends* stuff, that'd be nice. I only see it included from Source/cmLocalUnixMakefileGenerator3.* which means if the Makefile learns about depfiles, we can start removing cmDepends* (yay!). I guess the IDE generators rely on IDE magic to get dependencies correct? Y'know, I didn't really know. So, I spent longer than I'd care to admit in a find|grep loop examining the source. Raw notes as I progressed are appended to the bottom of this post, but the takeaway is that there are only really four kinds of generators: * Makefiles * Ninja (Some depfile solution) * Visual Studio (maybe VisualD will help handle things for us) * XCode (absolutley no idea) Everything else is implemented on top of those. All the non-VS non-XC generators ultimately go through cmLocalUnixMakefile3 and cmDepends, or they go through Ninja. So, we'll still need to get Ninja, VS, and XCode dependency separately, but cmDepends handles the all other generator's dependency resolution. So...it looks like this is what we're aiming for: - DMD/LDC - Support make-style depfiles (optional; unlikely) - Support filtering out excess dependencies (private import, system files) (preferred) Right now I'm doing direct dependencies only, so if module foo imports std.stdio, it adds a dependency on stdio.di, but nothing else. I think we might actually want full (recursive) dependency listings though, because of how templates work. Alternatively, I can just check the module names and filter out std.* and similar. - Ninja - dmd depfile support (preferred; no comment from martine yet) - CMake - Add depfile support to Make (preferred) - Add dmd - make depfile translator (likely necessary[2]) Like I said above, that's what I'm doing in cmDependsD at the moment. Since Ninja, VS and XCode all do their own thing, I think its fine to leave that translator inside cmDependsD. --Ben [1]http://stackoverflow.com/a/16969086 [2]The dmd-depfile format probably won't fly with make upstream since make-depfiles aren't actually a thing with make, but gcc. Whatever CMake does with their depends.make (I didn't go that deep), it works on all of the different Makefile generators CMake supports. - Trent What follows is my notes as I sorted things out: The method cmLocalUnixMakefileGenerator3::WriteDependLanguageInfo() calls into the cmDepends* system. This method is called by cmMakefileTargetGenerator::WriteTargetDependRules(). This in turn is called by WriteRuleFiles in cmMakefileExecutableTargetGenerator and cmMakefileLibraryTargetGenerator, which is called by cmLocalUnixMakefileGenerator3::Generate(). The cmLUMG3 will be set as the local generator for every cmGlobal*Generator except for Kdevelop, Ninja, VisualStudio and XCode. Upon inspection: * Kdevelop uses the Unix Makefile generator behind the scenes * Ninja does its own thing * VisualStudio does its own thing * XCode appears to do its own thing There are also cmExtra*Generators, for completeness, I'll inspect them too. * CodeBlocks: uses another Makefile generator * CodeLight: uses a Makefile generator or Ninja * Eclipse: uses a Makefile generator or Ninja * Kate: Makefile or Ninja * Sublime: Makefile or Ninja
Re: CMake with D support early snapshot
On Thursday, 27 March 2014 at 01:16:57 UTC, Ben Boeckel wrote: On Thu, Mar 27, 2014 at 00:38:05 +, Trent Forkert wrote: On Wednesday, 26 March 2014 at 23:17:31 UTC, Ben Boeckel wrote: 4. Add depfile support to Makefile generators. That's basically what I'm doing, though only in the context of D. No, I meant, using the DEPFLAGS during the make build (like ninja does) rather than doing it at configure time. I've tested this by creating a wrapper script around dmd to log calls to it in a file. Using that, I can confirm that cmDependsD does nothing at configure time. Granted it didn't refresh the deps file when I updated my D code, but... I've also tested with a simple C project (to confirm I no D-related bugs get in the way) that depend.make is generated and updated at build time. After building, I went and updated my C file to point to a new header it hadn't touched before, re-ran make (not cmake), and checked that depend.make listed now the header as a dependency (it did). To be extra sure, I reverted the change to the C code, and ran make again. depend.make was updated to remove the header dependency. The reason cmDependsD didn't update deps at build-time when I tried appears to be a matter of implementing another method I haven't got to yet. You're right that examine_d_source only worked at configure time, but cmDepends works at build time. Ninja is fine with the 'deps = dmd' solution. I will go with that then. VS will need VisualD I imagine (probably fine to require) It absolutely does. and XCode will need someone who cares enough to look into it (not me...) ;) . A cursory search finds a[1] few[2] solutions[3], but that's about the limit of my attention span for XCode+D right now. Yeah, I'm set up to work on Windows and Linux at the moment. Despite using a Macbook, I almost never touch OS X ^_^. Recursive public (non-static?) imports is the proper, minimal way to do it; you may be getting an import implicitly via another forwarding module. Like I said above, that's what I'm doing in cmDependsD at the moment. Since Ninja, VS and XCode all do their own thing, I think its fine to leave that translator inside cmDependsD. I think I was unclear: I'd like to see the dependency resolution done at build time, not configure time. That's why there'd be something like: %.o: %.d %.d: %.dmd.d -cmake -DINPUT=$ -DOUTPUT=$ -P cmake_root/CMakeDMDToMakeDeps.cmake -include $(wildcard *.d) I can do something like that if its needed, I think. cmDependsFortran appears to generate dependency rules that call CMake, and 'cmake -E cmake_depends ...' is the command that is actually used to generate a depend.make. But, as I said above, cmDepends is a build-time thing. It's more obtuse about it than the Ninja generator is, but it is still build-time. My understanding (without looking): the extra generators basically do some scaffolding to write IDE files which just tell the IDE how to run the internal generator, possibly with a list of targets, sources, and whatnot for those which can't manually inspect the build files themselves. Correct. - Trent
CMake with D support early snapshot
Hello all, Given the recent chatter and movement on CMake D support, I've decided to go public with a project of mine earlier than I had intended. Before I go further, a request: do *not* post this to HN/reddit/etc just yet. It is still in early stages and an upstream CMake 3.0 release (without D support) is incoming. Announcing this far and wide will only yield confusion at this time. So, what is this? It's CMake, with various modifications to work toward making D a first-class citizen of the CMake world. While other projects exist that attempt to add D support, they all do so without touching CMake's C++ sources. This means that they will inevitably fall short of the mark. Additionally, when I first started toying with this several months ago, there were a lot of implementation/design issues in the existing projects, that went against the way CMake's internals expect things to be done. I'm not sure how the current scene is in that regard. Status * GDC is fully supported, as is DMD master * LDC and older DMD's will work for simpler projects, but won't handle linking external libraries at the moment. I had a hack workaround for this before, but recently removed it when restructuring things a bit. * 32-bit DMD on Windows can't really be used for a C/C++/D mixed project right now because of problems I'm having with Optlink * VisualD generation works (tested on VS 2010 and VS 2012) * Makefile generation (and similar generators) work * Works on Windows and Linux. OS X ought to work, but is untested, as I don't have my OS X dev environment set up at the moment * D is listed on the CMake Qt GUI, which is nice Github: https://github.com/trentforkert/cmake Wiki: https://github.com/trentforkert/cmake/wiki Binaries: https://drive.google.com/folderview?id=0B5vzzNch4TtET09HM0NLWURKV1Uusp=drive_web#list As is tradition here, destroy! - Trent
Re: CMake for D
On Tuesday, 25 March 2014 at 01:15:10 UTC, Trent Forkert wrote: On Monday, 24 March 2014 at 23:55:14 UTC, Dragos Carp wrote: Any alternatives?? I moved cmaked2 to github [1], updated and simplified the usage a little (system cmake patch not necessary anymore). You can give it a try. Dub registry support is also on the way. Regards Dragos [1] - https://github.com/dcarp/cmake-d Heh, seems I waited a bit too long, eh? I've been gearing up to do an initial release of some modifications to CMake that give better D support. (To clarify: this isn't being merged upstream yet, but hopefully that'll happen eventually) While the approach taken by CMakeD2 and cmake-d gets a good amount of the way there, it lacks key CMake features. Namely: Visual Studio support, which unfortunately requires patching the C++ source. The module-only approach also cannot support LDC (save via ldmd, which is not ideal), as CMake will think it is a linker. There were other problems I encountered that required changes to the C++ code as well, though I don't recall what they were off the top of my head. Realized late last night that I misspoke. LDC and LDMD will both be detected as a linker, and the change to fix that doesn't touch the C++ source, but it does need to be done in CMake's internal modules. - Trent I'm curious to see how you intend to do dub support, though. - Trent
Re: CMake for D
On Monday, 24 March 2014 at 23:55:14 UTC, Dragos Carp wrote: Any alternatives?? I moved cmaked2 to github [1], updated and simplified the usage a little (system cmake patch not necessary anymore). You can give it a try. Dub registry support is also on the way. Regards Dragos [1] - https://github.com/dcarp/cmake-d Heh, seems I waited a bit too long, eh? I've been gearing up to do an initial release of some modifications to CMake that give better D support. (To clarify: this isn't being merged upstream yet, but hopefully that'll happen eventually) While the approach taken by CMakeD2 and cmake-d gets a good amount of the way there, it lacks key CMake features. Namely: Visual Studio support, which unfortunately requires patching the C++ source. The module-only approach also cannot support LDC (save via ldmd, which is not ideal), as CMake will think it is a linker. There were other problems I encountered that required changes to the C++ code as well, though I don't recall what they were off the top of my head. I'm curious to see how you intend to do dub support, though. - Trent
Re: Move VisualD to github/d-programming-language ?
On Thursday, 12 September 2013 at 15:55:26 UTC, deadalnix wrote: On Thursday, 12 September 2013 at 11:30:57 UTC, PauloPinto wrote: I don't get the point, what there is VM like when I compile Java, Scala, F#, C# native code? Compiling such language to native code require horribly convoluted code generation. For instance, an helloworld in java compilled natively with gcj gives you a 50Mb (!) binary blob. GCJ also doesn't offer improved performance over the JVM for non-trivial code. It will reduce the startup time, since no JIT is needed, but beyond that it doesn't really offer benefits. Not sure about other VM-native compilation
Re: Had another 48hr game jam this weekend...
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote: We have to get the user experience and first impressions under control... I'd really love to to see a general roadmap and list of priorities. Even if goals are high-level, they might help direct focus? So I had another game-jam this weekend with a bunch of friends who are all industry professionals. The point of a 48 hour game jam is to prioritise productivity and creativity. Choosing a language like D here makes sense from a productivity point of view... that is, if it 'JUST WORKS'™. There were 7 programmers, they were all using D for the first time (except me). Most running windows, one on OSX, one on Linux. We ran into the same problems old that have been giving me the shits as long as I've been using D. Configuring compilers: Naturally, this is primarily a problem with the windows experience, but it's so frustrating that it is STILL a problem... how many years later? People don't want to 'do work' to install a piece of software. Rather, they expect it to 'just work'. We lost about 6 hours trying to get everyone's machines working properly. In the context of a 48 hour game jam, that's a terrible sign! I just kept promising people that it would save time overall... which I wish were true. The only compiler you can realistically use productively in windows is DMD-Win64, and that doesn't work out of the box. We needed to mess with sc.ini for quite some time to get the stars aligned such that it would actually compile and find the linker+libs. Walter: DMD needs to internally detect installations of various versions of VisualStudio, and either 'just work', or amend sc.ini on its own. Or the installer needs to amend sc.ini. Either way, leaving it to a user to fiddle with an ini file just isn't acceptable. We had to google solutions to this problem, and even then, we had trouble with the paths we added to sc.ini; are spaces acceptable? Do they have quites around them?... I might also suggest that Microsoft supplied (ie, 'standard'), libraries should be automatically detected and path entries added in there too: C:\Program Files (x86)\Microsoft SDKs\... C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\... These are on basically every windows developers machine, and each of us had to configure them ourselves. Getting a workable environment: Unsurprisingly, the Linux user was the only person happy work with a makefile. Everybody else wanted a comfortable IDE solution (and the linux user would prefer it too). ! This has to be given first-class attention! I am completely and utterly sick of this problem. Don made a massive point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress how absolutely important this is. ! I have come to the conclusion that treating IDE integration as ancillary projects maintained by usually just one single member of the community has absolutely failed. I suggest: * These should be made central D community projects. * I think they should be hosted in the same github organisation as DMD. *** As many contributors as possible should be encouraged to work with them every day. - Deprecate DMD makefiles. Seriously! Insist that contributors use the IDE bindings to work on DMD. - The fact that you all laughed at the prior point suggests clearly why it needs to be done. It will cease to be a problem when all the druntime/phobos contributors are suffering the end-user experience. * They should receive bugs in the main github bug-tracker, so EVERY D contributor can see them, and how many there are. IDE integration absolutely needs to be considered a first class feature of D. I also suggest that the IDE integration downloads should be hosted on the dlang download page so they are obvious and available to everyone without having to go looking, and also as a statement that they are actually endorsed by the dlanguage authorities. As an end-user, you're not left guessing which ones are good/bad/out of date/actually work/etc. Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the only realistic choices available. The OSX user would have preferred an XCode integration. Overwhelmingly, the biggest complaint was a lack of symbolic information to assist with auto-completion. Visual-D tries valiantly, but it falls quite short of the mark. This goes back to the threads where the IDE guys are writing their own parsers, when really, DMD should be able to be built as a lib, with an API designed for using DMD as a lib/plugin. I think continuous code compilation for auto-completion and syntax highlighting purposes should be a service offered and maintained by DMD. That way it will evolve with the language, and anyone can use it without reinventing the wheel. Debugging: Poor debugging experience wastes your time every 5 minutes. I can only speak for the Windows experience (since we failed to get
Re: Build / Package system
On Thursday, 25 July 2013 at 17:59:23 UTC, Elie Morisse wrote: On Wednesday, 30 May 2012 at 08:13:34 UTC, Sputnik wrote: There is a build and/or package managment system for D2 that is working? I googled, and I only can find things like dsss or cmaked that don't get updated from a long time ago. I really need to manage to get a project to compile in Windows and Linux. Actually the code not have any OS dependence, so the real diferences in each OS are the linking to gtkd and how and where install the project. Actually I'm using a makfile in Linux that works well, but I can't use it in windows for thing like pkg-config. CMakeD is actually just a bunch of CMake modules and very lightweight, it wouldn't be surprising if it still worked or required more than a few minor changes. I've decided today to migrate my project from C++ to D after being annoyed by the lack of conditional evaluation of code in C++ and the opposition of the core designers of C++ to static if, so I will report later if CMakeD is still useable. The thing about CMakeD(2) is that, by my recollection, it *needs* to be installed in CMAKE_ROOT. It also doesn't support LDC, technically doesn't detect compilers correctly, and sets variables that will break multi-language projects. There's a lot to fix with it, it won't be a simple set of changes. And it won't be something you can consult documentation for, as CMake internals are very poorly documented. That said, I've been working on a new collection of D-related CMake modules for the past month or so. Real life (and Minecraft and DOTA2) have been encroaching on my free time lately, but progress is being made. Right now, I have a D project, which references a C library built within the same project tree, and things are working on Linux x86_64 with recent versions of DMD, LDC, and GDC. I'll be doing testing and tweaks this weekend, and if it looks like things are working, I'll move toward getting this documented and put on github. It's not quite there yet, and the API has changed twice in the past week as I deal with CMake quirks, but I should have enough feature completeness for a v0.1 this next week. I have ideas kicking around for some potentially interesting features (dub integration of some sort?) that *definitely* won't be ready for the v0.1, but they'll be coming. Good news is, integration into CMake's sister tools (CPack and CTest) is super easy, so standard installers/archives/packages for the various platforms will be supported the same as C++ based CMake projects. Soon...
