Add ability to declare C dependencies

[TobiasWrigstad]

Non-trivial use of embed ... end requires ability to include header files and also build dependencies. A possible mock syntax would be to enable lib and inc statements inside embed blocks, e.g.,

embed T 
  inc ./relative/path/to/bitset.h 
  lib ./relative/path/to/bitset.o
  ...
end

The goal is to be able to skip having to generate a C file and manually edit it and compile it.

[EliasC]

Let's add this as top-level constructs, i.e. on the same level as class-declarations. We're going to need the same kind of machinery when we do imports and stuff anyway.

_c_inc ./relative/path/to/bitset.h
_c_lib ./relative/path/to/bitset.o

import EncLib

class Foo
    ...

[TobiasWrigstad]

Sounds good.

[kaeluka]

I can take care of this tomorrow.

[TobiasWrigstad]

Great! Thanks!

[kaeluka]

Although prettier, @EliasC's approach lacks power. I'm going to implement a toplevel embed statement that let's you merge in C code, just as @TobiasWrigstad suggested originally.

Example use case: some libs require you to use a preprocessor #define before you include them.

[EliasC]

Agreed! This will also allow you to define C-functions in your program, which could be useful!

[kaeluka]

You can find the test of the feature here: https://github.com/parapluu/mylittlepony/blob/a7234e492d35cca65a252c2a942d4e0dca62ebcc/src/tests/encore/basic/embed-tl.enc

[TobiasWrigstad]

I am not sure it was correct to close this one. I believe what you have done is very useful (THANKS!), but it is not all what this ticket was about. This allows me to do includes at the top-level which is great, but it does not take care of the lib part, which was more about telling the encore compiler what compilation string to generate with libraries, etc. Granted, the most urgent part is done, but let's make sure the other part is at least discussed and not lost.

[supercooldave]

Looks like we are after an FFI between Encore and C. Adriaan has expertise in this area.

Sent from my iPhone

On 20/07/2014, at 19:03, TobiasWrigstad notifications@github.com wrote:

I am not sure it was correct to close this one. I believe what you have done is very useful (THANKS!)l, but it is not all what this ticket was about. This allows me to do includes at the top-level which is great, but it does not take care of the lib part, which was more about telling the encore compiler what compilation string to generate with libraries, etc. Granted, the most urgent part is done, but let's make sure the other part is at least discussed and not lost.

—
Reply to this email directly or view it on GitHub.

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[albertnetymk]

The lib dependency shouldn't be addressed on per file based. The included
header ensures the current unit to compile, and the lib only comes into
account in linking.

It's possible that one lib is shared by multiple units in one project, and
there should be one place to list the external lib dependency for the final
executable, instead of each object file.
On Jul 20, 2014 7:03 PM, "TobiasWrigstad" notifications@github.com wrote:

I am not sure it was correct to close this one. I believe what you have
done is very useful (THANKS!)l, but it is not all what this ticket was
about. This allows me to do includes at the top-level which is great, but
it does not take care of the lib part, which was more about telling the
encore compiler what compilation string to generate with libraries, etc.
Granted, the most urgent part is done, but let's make sure the other part
is at least discussed and not lost.

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[TobiasWrigstad]

The embed is just a hacky way to get around stuff that we currently do not have. Your comments might be valid if we were talking about a more mature feature. Right now, we are just trying to get stuff to run.
Right now, as soon as we drop to C level, we can no longer use the encore compiler to compile our programs. A good way forward IMO is to enable the compiler to generate the right linking flags so that we can get programs to run with a minimum of hassle.

Once we are at the stage where there could even be one "project", we can revisit this. If we build a C FFI we do this good. Right now, we move forward. No external dependencies.

[kaeluka]

The embed is just a hacky way to get around stuff that we currently do not have.

But hacky features also need to be implemented in a specific way. What should the linker flags be if two equal-named .o files are requested by different files?

As we already have a lib directory, I suggest using that: the .o files you want to use have to be in the same directory as the .enc file or in the lib directory. Saves us wasting time on a hack and avoids the pitfall that @albertnetymk identified.

[TobiasWrigstad]

I wasn't aware we could compile different files at the same time. Can we?

[EliasC]

We can not.

[kaeluka]

No, but we're planning to do that soon, was my view.

Anyway, I just pushed a small temporary fix (41b00ee) that changes the compiler to use the *.o files in the current directory. The embed-tl test is an example of usage. This should allow you, @TobiasWrigstad, to continue. Next week, we can talk about how exactly this feature should look. Sounds good?

I'm reopening this ticket now.

[TobiasWrigstad]

Thanks @kaeluka! I'll look at the temp fix. I suggest we might not look at how to fix this the coming week, but put several tickets in the system for compiling multiple files, C FFI, the works. The most urgent thing, though is a very short language spec that documents how Encore works.

[kaeluka]

@TobiasWrigstad see #17

[TobiasWrigstad]

@kaeluka What is the status of this? Can this be closed?

[TobiasWrigstad]

Thanks you!