dstep
dstep copied to clipboard
jacob-carlborg
-o <directory> appears not to work
|> dstep -o LibDVBv5 /usr/include/libdvbv5/dvb-{fe,file,frontend,scan}.h
dstep: an unknown error occurred: std.file.FileException@/build/ldc-1.1.1/runtime/phobos/std/file.d(536): /usr/include/libdvbv5/dvb-fe.d: Permission denied
----------------
std.file.FileException@/build/ldc-1.1.1/runtime/phobos/std/file.d(536): /usr/include/libdvbv5/dvb-fe.d: Permission denied
----------------
IIRC, for some reason I decided to place the output in the same directory as the input files, in this case /usr/include/libdvbv5. That should be fixed to use the current directory instead.
I'll hack around it for now so I can do stuff, but as soon as a fix is available I'll ditch the hack.
It appears that the libdvbv5 C header files are all interrelated. Creating separate D modules for each file is not going to lead to any success. It seems that all header files have to contribute together to make a single D module. It seems I need this many-to-one name problem solved in order to progress. Sorry.
Definitely getting the more expected behaviour!
This now creates a D module per C header file in the directory specified. So in a sense success. However, the libdvbv5 C header files are interrelated, symbols from one file are used in another.
However, the libdvbv5 C header files are interrelated, symbols from one file are used in another.
Is that a problem when you generate the D modules or when using them?
If I generate individual D modules one per C header file, the individual modules will not compile.
One big issue with translating multiple headers separately is this one https://github.com/jacob-carlborg/dstep/issues/101 - because of how common such forward declaration are in C code I had to cleanup generated modules by hand for most multi-header conversions I did.
If you want to completely automate the process converting all headers into single big D module is much more reliable.
I have opened issue #139 to deal with the multiple header files to avoid changing the content of this issue. I think the -o problem has been solved in the DStep code base now, so I am closing this issue.
Actually it has not. 1. it's not in master, 2. it was not a correct fix. The issue is in std.path.buildPath that DStep is using. It has (in my opinion) the unexpected behavior of that the following assert holds true:
assert(buildPath("/foo", "/bar") == "/bar");
I expected buildPath("/foo", "/bar") to result in "/foo/bar".
Ah, I forgot, I build from a feature branch. Sorry about that.
The manual on std.path states that buildPath("/foo", "/bar") results in "/bar", I suspect because it is assuming the second is an absolute path. buildPath("/foo", "bar") results in "/foo/bar".
Exactly, I just expected a different behavior and didn't read the manual 😃. I've never used another language which has a function with the same behavior and I don't see what it's good for.
I'll rant on the email list. It won't change anything, because… Phobos. But it will make me feel better.
There is an issue 136 branch, is that changeset redundant, or does it need to be merged in to master?
OK, I guess I have to wait a while before progressing the DStep side of the libdvbv5 work – I want to find a way of automating the manual changes to the result of DStep so as to minimise the effort of updating. However libdvbv5 updates are very infrequent, so we have a while before it becomes an issue. For now I can progress Me TV with what I have.