I have a library that has many folders and D files in them. I do not want to list name of all module files one by one while compiling projects. So, I thought I could use "-I" flag while compiling. It says:

-Ipath
    where to look for imports

So, I made a test as follows:


./test.d
==================================
import inc.blah;

void main(){
	inc.blah.a = 5;
}


./inc/blah.d
==================================
module inc.blah;

public int a;


./makefile
==================================
all:
	dmd -I"./inc/" test.d


When I do "make", result is as follows:

dmd -I"./inc/" test.d
test.o: In function `_Dmain':
test.d:(.text._Dmain+0x10): undefined reference to `_D3inc4blah1ai'


Do I understand wrong how that "-I" flag works?

On 29/01/2015 8:08 p.m., tcak wrote:
> I have a library that has many folders and D files in them. I do not
> want to list name of all module files one by one while compiling
> projects. So, I thought I could use "-I" flag while compiling. It says:
>
> -Ipath
>      where to look for imports
>
> So, I made a test as follows:
>
>
> ./test.d
> ==================================
> import inc.blah;
>
> void main(){
>      inc.blah.a = 5;
> }
>
>
> ./inc/blah.d
> ==================================
> module inc.blah;
>
> public int a;
>
>
> ./makefile
> ==================================
> all:
>      dmd -I"./inc/" test.d
>
>
> When I do "make", result is as follows:
>
> dmd -I"./inc/" test.d
> test.o: In function `_Dmain':
> test.d:(.text._Dmain+0x10): undefined reference to `_D3inc4blah1ai'
>
>
> Do I understand wrong how that "-I" flag works?

Basically during linking not all symbols used is passed in.
You are doing a single compile + link.
So what -I does is tell the compiler to look for definitions in files on the paths specified. But does not compile them into the binary output.

I would suggest instead of using make, use dub[0] build manager instead.
It'll handle grabbing all the files and compiling them correctly.

[0] http://code.dlang.org/package-format

> I would suggest instead of using make, use dub[0] build manager instead.
> It'll handle grabbing all the files and compiling them correctly.
>
> [0] http://code.dlang.org/package-format

Or for simple projects such as this one seems to be, just use rdmd.

Atila

On Thursday, 29 January 2015 at 10:26:56 UTC, Atila Neves wrote:
>> I would suggest instead of using make, use dub[0] build manager instead.
>> It'll handle grabbing all the files and compiling them correctly.
>>
>> [0] http://code.dlang.org/package-format
>
> Or for simple projects such as this one seems to be, just use rdmd.
>
> Atila

I am using Mono-D on MonoDevelop. I was normally keeping all library files in the same project. But copying same library codes between different projects didn't seem like a good idea.

Then I copied library files as "symbolic link" to project, but this time, if I put a new module in library folder, Mono-D doesn't see it automatically.

Then I saw "Include" part in project properties which uses "-I" flag while compiling the project. I removed all symbolic links from project, and added full folder paths of libraries to that "Include" list.

As you can guess, as I asked in the question, it doesn't see library files now. I still have a solution as linking to library modules, but I wondered whether it was possible in another "easier" way.

Let me try to explain the compilation process which may help you to understand where your problem lies.

* Build system
	* Maintain program/library dependencies
	* Execute commands resulting in a usable program/library
* Compiler
	* Lexical Analysis
	* Parsing
	* Language translation
	* Optimizations
* Linker
	* Combine machine code from multiple locations
	* Optimizations

Each stage is feeding into the next and interacting with one may not require explicit interaction for the next.

=== Linker
The linker is at the bottom of our list because it will be the final step in creating an executable/library. There is not one single linker, there are many for different operating systems and programming languages. The 'ld' linker is common on Linux, Windows has a linker called link, and DMD makes use of optlink for its 32-bit build.

At the time the linker is called the source code has already been translated into machine code by the compiler. So the linker has a simple task of packaging up the machine code which makes up your program. This means locating the machine code for libraries being used and combining it with the instructions you've specified. One of the most common errors you'll receive from a linker is that it can't find the corresponding machine code.

Consider yourself the linker and, as the compiler, I will request that you do some work for me. The programmer has asked me to compile decentApp.d for them and makes a call to spiral(). If I give you the machine code for decentApp could you please include the machine code for famous.awesome.spiral() too? Are you able to locate machine code for famous.awesome.spiral?

The answer is that you can't, not with out being told where to look, what to look for, or searching every location for any machine code matching that symbol (when you make function calls the linker doesn't care it is a function, it considers it a symbol or reference for some chunk of machine code).

The solution, tell the linker where it will find the code, it is just a polite thing to do.

Once the linker has all the code it can perform optimizations, one of the most common is throwing out code which isn't being used.

=== Compiler
The compiler is a translation tool, making conversion from one language to another.

When it translates a chunk of code, there can be references to other chunks some of which may have already been compiled, and some that may still need compiled. What is important to the compiler is making sure that the call out to that chuck of code is formed in the agreed upon structure. It does this by examining the function signature, in C/C++ we see this information provided through a header file.

Since the compiler doesn't have to build every chunk of code that the program is being run, as long as it has the function signature it can translate code that call into some unknown location. And this is where the -I flag comes in play. When you provide the -I with a location, it signals to the compiler that it should look for the function signatures of this code chunk in the locations specified.

However, the compiler does not build the code that it finds, it expects you have already done that because you're not telling it to build that code. It will then pass off the translated code to the linker and request an executable be built.

The linker however only knows about the code the compiler has told it about (and some default search locations). If it can find it in the code provided by the compiler, or the places it was told to search then it will fail.

This is where the -l linker flag comes in (assuming Linux), when passed on the compiler it would be -L-l (pass to the linker the flag -l). Using -l specifies what libraries to find reference code in, and -L is used to specify what directories to look in for the requested library.

----

When you tell the compiler to build your code and it will find some of the code over here in -I"foo" it is probably wrong if you don't also include a -L-l and possibly -L-L in that same command.

Most likely you want a build system that handles dependencies for you, check out DUB.