Static Library Support: Project dependency to static libraries

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

 

Advertisements

Static library support

After some messing around the EGit finally I came to understand how to push my changes to the google code clone. It came as a surprise because I was sure that I understand the git architecture. The problem was that I had proper ref specs to the google code clone’s repository.

Today’s exercise was to add some support of static libraries. I found that the DeeBuildOptions class had some traces for supporting different build types but it was set to EXECUTABLE without the option to change it. In the case of static library, the DMD compiler offer an option “-lib” to build static libraries. In addition I found that the there were already a combo box to set the build type in the DeeProjectOptionsBlock which is responsible for handle the compiler options in the UI.

So this part of the job was pretty easy: Uncomment the relevant part in the DeeProjectOptionsBlock.createControl method that shows the combo box for the build type setting. To handle the default cases better than we do currently, I hid all the properties of the DeeBuildOptions class and added some handling of the default values. If there’s no set output directory yet, it will depend on the build type, for instance: if the build type is executable or dynamic library, the output directory is ‘bin’, if the build type is static library, the output directory will be the ‘lib’ directory. However, I noticed a tiny little problem here. The D programming language is a native language which means that the compiled modules are subject of linking. That is, the real output of the build process is the executable/library/dynamic library and the object files themselves are kind of a by-product of this process. Most of the build system I saw there were a separation between the intermediate files (object files) and the final output. As a next step I would like to add an intermediate directory for the object files to handle (of course, if the user wishes so, he can keep the output files mixed with the object files).

On the UI with small little hack I only update those DeeBuildOption fields that were actually edited so that my changes on the default values could come to effect. But I need to updated the artifact name’s field which I just realized I didn’t. Next commit. If you switch to LIB_STATIC build type, the output folder and the output extension will change to lib.

Also, before I committed these changes I merged Bruno’s recent changes (mostly GDC related stuff).

The corresponding change set in the source code: r080d4e50bc25

IModelElement Icons

My previous experiments with DDT were about to change how the Outline View looks like in DDT. It was a good exercise to understand the Eclipse plug-in development basics and learn Bruno’s code. However, it didn’t work out as I expected as it took quite a while to understand how the DLTK assist the plug-in to build a model from the source code. This IModelElement hierarchy represents the basic model of the project’s tree and therefore this is to be used by any graphical representation as it is in the ScriptView or the OutlineView.

Later Bruno unified the whole stuff in the DeeModelElementLabelProvider which works in three different context: Script View (navigation), Outline View (view), and the Completion Proposal (CodeAssist). As I can’t settle with the current icons I decided to change this bit of the code. Bruno made it clear that he wants to use the private/public/protected modifiers as an overlay, but I rather would not use that in the case of fields and methods. The reason for this is simple: The overlayed icons have limited space, and a field (variable) or a method (function) could possible have quite a few modifiers such as “private static immutable” thus having three overlays would look like quite crowded.

As a result, I brought my previous patch in play, adding the JDT’s icons for methods and fields. At the moment I didn’t add other things, but it only needs a little painting to get a private/public/protected overlay for other elements, such as classes, structs, enums, interfaces, etc.

I couldn’t find my complete previous work however: Previously I added the types/return types to all these fields, similarly to JDT. Anyway, the stuff looks like this right now:

The corresponding change set in the source code: r427c36a3c2e4

Features that worth to look at

DDT is still quite immature so there are plenty of features missing to make it a productive development environment. Browsing in the code and messing with the product it self I decided to come up with an approximate list of features which should be implemented in order to make DDT worth to work with as a IDE for D development in the long run. The following list will change a lot in the future as I will revisit in the light of ongoing development.

Static and Dynamic library support: In a real software ecosystem static libraries are essential more than anything else. To add the static library support seems easy, but I haven’t tried any dynamic library with D yet.

Debugger support: This is perhaps the biggest one. There is no development IDE without a useful debugger interface and unfortunately DDT is lacking one. And also, this is quite a problem with D in it self. As far as my experiments went, the only compiler that produces some meaningful debug-info is DMD, but we have a limited support for command-line based debuggers. GDB would be a perfect choice, but at the moment I have no convincing evidence that the GDB’s D support is working to this moment. I need to investigate the matter further.

Refactoring: The CodeAssist for D is quite promising and I don’t see any issue to implement the most popular refactoring strategies: it’s just matter of time and arse.

Unit-testing IDE integration: It is imperative in the software development these days to offer a good, reliable testing facility for the developers. JUnit has an excellent support in Eclipse, where you can track in a graphical way what unit tests are present in the source code and we can have a good report on their progress in the test view.

As a frame work, I think it worth to have a look at the Felt project as it is aimed to provide all the agile goodies through several library. The DUnit framework in particular provides the unit testing framework which I could build a IDE support for. The real deal here is to parse the output of the unit test executable. Unfortunately it seems to rely on the Tango library which I find quite disturbing as the Tango is an optional library, but in this case all software that would use the Felt libraries, will depend on Tango. As the Felt library was updated quite a long time ago, as I try to explore it, I should remove the dependencies to the Tango library.