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
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
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,
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
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
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
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
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
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
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).
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
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
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
maintenance when source files are added/removed/renamed.
- Trent
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
.
=
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
work is independent of CMakeD2 and its
forks. See my project wiki for more info.
- Trent
[1] https://github.com/trentforkert/cmake
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
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
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
. -deps=DEPFILE doesn't output all
the same information as -deps DEPFILE. Same holds for GDC
and LDC equivalents.
- Trent
,
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
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
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
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
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
/folderview?id=0B5vzzNch4TtET09HM0NLWURKV1Uusp=drive_web#list
As is tradition here, destroy!
- Trent
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
. 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
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
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
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
32 matches
Mail list logo
