модули в D

Ubuntu 7.10, dmd-1.028, всё работает.

Решение проблемы зависит от того, что ещё вы пытаетесь загрузить. С ключами компилятора я особо не разбирался, т.к. использую DSSS, но, вроде, достаточно указать пути к исходникам используемых модулей (ключ -I )и перечислить относительные пути к компилируемым файлам.

Kubuntu 8.04. DMD 2.012 без DSSS и GDC 0.24 с DSSS - всё работает.

M$ Windows XP SP1. DMD 1.010 с DSSS - последний раз смотрел - работало.

т.е. import ******; достаточно если с IDE? (я в этом ещё юзер)

> я в этом ещё юзер

Ясно.

В файле с исходником после module пишется его полное имя (пусть будет A). Если модуль A должен использоваться из модуля B,
то в исходнике с модулем B нужно написать import A. И всё.

dmd передаётся список исходников и он из них делает объектные файлы и линкует в исполняемый файл. Если передать ключ -c,
то исполняемый файл создан не будет. При компиляции имя модуля остаётся в объектном файле. Объектный файл можно давать
компилятору так же, как и исходники и он будет прилинкован. Например:

//Файл A.d
module A;
import B;

void main() {
    foo();
}

//Файл B.d
module B;
import std.io;

void foo() {
    writefln("Called Foo!");
}

Можно скомпилировать так:
$ dmd A.d B.d

Можно так:
$ dmd -c B.d
$ dmd A.d B.o

Или даже так:
$ dmd -c A.d B.d
$ dmd A.o B.o

А можно установить dsss, создать dsss.conf с одной строчкой:
[A.d]

и скомпилировать с автоопределением зависимостей:
$ dsss build

Если B.d был написан и скомпилирован в либу до нас и исходников у нас нет, то нужно делать так:

$ dmd A.d B.di -L-lB.a

Нужно перечислить *.di для всех interface файлов и не забыть прилинковать соответствующую либу ключом -L-l[имя_либы]

Или, если либа была установлена через dsss:

$ dsss build

С тем же dsss.conf, что и в предыдущем примере.

И вообще RTFM ;) :
http://digitalmars.com/d/2.0/lex.html
http://dsource.org/projects/dsss

> import ******; достаточно если с IDE?

С Poseidon или Code::Blocks - достаточно. только нужно им показать где лежат либы и *.di к ним. У Descent пока своего билдера нет.

А лучшая среда разработки - vim + dsss ;)

> $ dmd A.d B.di -L-lB.a

Здесь немного соврал.

$ dmd A.d B.di -L-lB

А файл должен называться libB.a

>А лучшая среда разработки - vim + dsss ;)

offtop {

Чем dsss лучше make-а для простых проектов? Я правильно понимаю, что это нечто крутое вроде maven-а?

}

С maven не работал.

DSSS чаще сравнивают с CPAN и Gems. Это система для установки софта из исходников со всеми зависимостями из центрального репозитория. Для разработчика DSSS - система для автоматизированного билда. Я использую его для всех своих проектов. Обычно dsss.conf выглядит так:

-----------------------------------------------

name = my_project

[mycompany/myproduct/mylib]

target = mylib

[mycompany/myproduct/anotherlib]

target = anotherlib

[mycompany/myproduct/myapp/main.d]

target = myapp

-----------------------------------------------

С зависимостями, incremental build'ами, прилинковываемыми библиотеками, различиями между компиляторами и платформами он разбирается сам.

make менее удобен для проектов размером больше одного файла хотя бы тем, что в makefile'ах все зависимости ручками прописывать надо. Зачем, если они есть в исходниках?

Не судите строго, если где незаслуженно опустил make. Последний раз писал makefile чуть больше 4-х лет назад.

> make менее удобен для проектов размером больше одного файла хотя бы тем, что в makefile'ах все зависимости ручками прописывать надо.

> Не судите строго, если где незаслуженно опустил make.

Нет прощения >;-E

> Последний раз писал makefile чуть больше 4-х лет назад.

И под оффтопик...

> в makefile'ах все зависимости ручками прописывать надо. Зачем, если они есть в исходниках?

Не надо, пишем
program: main.d lib.d another.d
        dmd -of$@ $^

:)

Не тру, но dmd компилит весьма шустро, и на *небольших* проектах не заметно. Линкер работает дольше :)

Спасибо за ответ, всё понятно.

> dmd компилит весьма шустро, и на *небольших* проектах не заметно.

Проблемы начнутся, если проект *большой*. Размером скажем с DWT. :) И, прошу заметить, что в моём примере mylib, anotherlib и myapp вполне могут состоять из пары сотен файлов с исходниками, зависящими от библиотек сторонних производителей.

> Линкер работает дольше :)

Чтобы линкер работал быстрее, чем dmd, используйте optlink. Правда он понимает только OMF.

После релиза binutils с gold можно попробовать поэкспериментировать с ним.

> Проблемы начнутся, если проект *большой*.

Это понятно. Большому кораблю большую торпеду :)

Мне make нравится тем, что он простой как 2 рубля, в нём можно делать почти всё что угодно (потому что он, фактически, является интерпретатором декларативного ЯП), и я его знаю. Со сложными специализированными системами сборки зачастую бывает сложно делать простые вещи (это обобщённое утверждение, не обязательно про dsss).

Вообще мне сейчас нужны такие вещи: трансляция .apd файла используя apaged (и последующая его компиляция); сборка двух бинарников - 1 для прогона юниттестов, с отладочными опциями, второй после успешного запуска первого, с оптимизационными опциями. Ещё я не люблю, когда всё собирается в каталоге с исходниками, т.е. желательна возможность сборки в отдельном каталоге. Насколько это укладывается в схему dsss? Если это в нём несложно сделать, то перееду на него :)

> Чтобы линкер работал быстрее, чем dmd, используйте optlink. Правда он понимает только OMF.

Спасибо, посмотрю. Пока у меня объектные файлы только D-шные.

Можно сделать например так:


$ cat main.d
import tango.io.Console;

void main() {
        Cout("Hello!\n");
}

unittest {
        Cout("unittest\n");
}


$ cat dsss.conf
name = test

[main.d]
target = main
prebuild = ./makeApd.sh #Здесь транслируем apd
debugflags = -unittest -debug
releaseflags = -O -inline -release


$ cat make.sh
dsss clean
dsss build main --debug
./main
dsss clean
dsss build main
./main


$ ./make.sh
main.d => main
[команды]
unittest
Hello!

main.d => main
[команды]
Hello!

Обьектные файлы по умолчанию отправляются в каталог dsss_objs. Недостатки очевидны. Повсеместное использование
shell скриптов и (пока) невозможность сделать один target зависящим от другого. Можно только указать соответствующий
dsss build [зависимость] в prebuild скрипте зависимой цели. Преимущества я описал ранее.
Но если makefile уже есть и работает, думаю не стоит переписывать его на dsss.

> Пока у меня объектные файлы только D-шные.

optlink запускается только под оффтопик, принимает на вход только OMF (не обязательно скомпиленные dmd, можно, например, и очень
старыми MSVC) и выдаёт только PE. Для Линукса бесполезен... Зато быстрее, чем ld в 50-100 раз. :/