Last time I was dealing with the project build types that allowed DDT to produce static libraries out of a project. That’s a vital element for a larger project infrastructure so its implementation should be priority. This time there was an other problem related to the larger projects. It’s all nice and good to have lib files produced but we couldn’t really do anything with them at all.
Actually, the same way as most of my development I heavily relied on what Bruno did before. As far as I understood the already existing code the heavy lifting was already done. That is, the project dependencies on libraries were implemented as a skeleton, only that it wasn’t useful… yet. The only thing left to implement is to use the project dependencies’ output (the static libraries themselves) as input modules and their source directory as input directory on the referee project. But nothing is as easy as it looks. I’ve just encountered a quite disturbing fact: the DLTK documentation is just virtually non-existent. There are some vague articles in their wiki, but the API documentation is basically isn’t any useful. That makes life quite hard to develop anything on the DLTK basis and frankly I’m worried about the scenario when DDT hit huge problems with the DLTK. The actual issue I encountered looked quite easy: how can I get libraries from a different project and resolve their paths relative to the workspace. At this point of time I didn’t find anything useful for this. So at the time being I had to hack the references to other projects with a simple “../[projectname]/src” as an import directory and “../[projectname]/lib/[projectname].lib” as a input file. But the real solution would be to get access to the other project DeeBuildOptions object which could provide me the necessary settings for the output file, its build type from its IScriptProject info the source folders as they could be more than one.
In other words, to use this new feature the user has to make sure that the directory structure is that of the default and there are no additional source folders. Also it probably won’t work with anything but DMD and possibly only on Windows. The next target is to eliminate these problems.
The corresponding change set in the source code: r341098a21488
This blog is dedicated my work on the D Programming Language. Though my self had not even worked on a project and coded serious stuff in D I can see the possibilities and the real need of such a programming language. If you don’t know what is D, please refer to the official website.
I think when Walter Bright come to the conclusion that there’s a need for a multi-paradigm, imperative, native language, he made the right choice. As a C++ developer myself, I found several frustrating issue with my main programming language and with all the efforts of the recent C++11 standard these pains doesn’t seem to pass. I don’t want to bash C++: it’s a nice piece of language which stays prominent for many years if not decades, but I think today, in 2011 we need to prepare ourselves to learn from the mistakes of the past, and have a clear start. C++ is dragging many compatibility issues with it self along its long way, and therefore a new language design, free of such a heavy burden could mean a fresh start in the native development.
As of today, the most prevalent programming languages in the native arena is C and C++. C is good as it is, restricted system programming language which fit most of the hardware environment. C++ on the other hand, though it made an astonishing progress with the C++11 standard, has major flaw: it just doesn’t hold the challenge against the world of Java and C# world. These programming languages became success not because of their revolutionary new technology but from rather the fact that they can keep the developers happy and enthusiastic. All this is because it was easy to produce a wide variety of coding tools that makes the development fun. In order to maintain the momentum of the native development, we need to get the fun back to the native development.
C++ unfortunately can not offer such an easy entertainment. As a project is getting more and more complicated the build time grows enormously. It desperately calls for a module system. The parsing is difficult because the extent and ambiguity of the C++ grammar. The compiler can be hardly manipulated, the reflection system is partial, and a language level garbage collector would just make life easier for everyone if the coder can decide to not use it in certain, well limited scenarios.
In this series of blog post I document my experiments, understanding and contribution to the language D.