On 2014-01-10 19:35, Sean Kelly wrote:
Yeah, this is also one reason why I chose the header format I
did. It works directly from the spec and so imposes a structure
of its own rather than inviting direct ports of existing headers.
But I'm really just guessing here, since I don't have any legal
background.
One issue I'm not sure about regarding automatic translation
(assuming this is deemed acceptable). Say you're trying to
translate pthread.h on a Posix system. The declarations for that
file might be required to live in sys/types.h, but in actuality
live in a smattering of files in other locations (usually
bits/whatever) all selected by a pretty complex chain of
preprocessor conditions. If we were to do an automatic
translation, how would this all work? One thing I like about the
current approach is that the result is succinct and legible,
despite requiring more work to generate.
Yeah, I know. That's one of my big problems with DStep, what to do about
includes. Many types are hidden behind a typdefs to make it
cross-platform. The actual type is usually in an internal architecture
specific header file.
The advantage would be to have all the declarations automatically
translated but then manually put in the correct files. It does not
necessarily need to be, run one command and it's all translated.
Automatic translation could help even if it's not completely automatic.
Just to avoid any manual errors.
--
/Jacob Carlborg
