Compilation strategy

[Paulo Pinto]

On Monday, 17 December 2012 at 08:02:12 UTC, Adam Wilson wrote:
> On Sun, 16 Dec 2012 23:08:49 -0800, Jonathan M Davis 
> <jmdavisProg at gmx.com> wrote:
>
>> On Sunday, December 16, 2012 22:58:26 Walter Bright wrote:
>>> On 12/16/2012 10:27 PM, Jonathan M Davis wrote:
>>> > If the entire .d file is there in binary form, then I don't 
>>> > see why it
>>> > wouldn't work. .di files fail because they strip out the
>>> implementation.
>>> > If a binary format were used,
>>>
>>> It's all about what is in the file, not whether it is text or 
>>> binary.
>>
>> The concept of .di files and their ilk is fundamentally broken 
>> precisely
>> because they're trying to strip what's in the file. That's 
>> what causes the
>> problems.
>>
>>> > then we should be able to get away with keeping the
>>> > implementation there, because then it's obfuscated rather 
>>> > than for
>>> sitting
>>> > there for all to see, which is why corporations and the 
>>> > like insist on
>>> > distributing only headers. Even with an object file, the 
>>> > best that
>>> you get
>>> > is obfuscation, because it can always be reverse 
>>> > engineered, so it
>>> seems
>>> > to me that what needs to be avoided is providing text. As 
>>> > long as we
>>> use
>>> > text, we're forced to cut out the implementation and end up 
>>> > crippling
>>> any
>>> > code that uses that module, since it can't inline it or use 
>>> > it in
>>> CTFE.
>>> > In binary format, it's obfuscated, so the entire 
>>> > implementation can be
>>> > there, allowing inlining and CTFE to work.
>>>
>>> This method of obfuscation simply will not hide things from 
>>> someone with
>>> even modest technical ability, because *all* the source 
>>> information is
>>> *necessarily* there in the file.
>>>
>>> Object files are resistant to reverse engineering because 
>>> most of the
>>> information is gone.
>>
>> True, but they can stll be reverse engineered, and if the 
>> problem is that
>> companies don't want 3rd parties looking at their code, then a 
>> binary format
>> has obfuscated it and possibly solved that problem. Object 
>> files do make it
>> harder, but they can still be reverse engineered, so it really 
>> becomes a
>> question of what it takes to satisfy the folks who think that 
>> not giving the
>> whole information in a .d or .cpp file somehow protects their 
>> code (since it
>> doesn't really). And if a binary format can do that (as it 
>> seems to in Java
>> land), then that seems like a far better solution, because 
>> then we can leave
>> all of the information in there that inlining and CTFE need in 
>> order to do
>> their jobs. With .di files, we'll never get that.
>>
>> - Jonathan M Davis
>
> Putting it all in binary and calling it good isn't really a 
> solution. Like it or not, the C/C++ header file provides what 
> larger corporations with IP to protect want. Difficult to 
> reverse (not impossible, but they know that and are willing to 
> accept it) with easy to access plaintext headers so the 
> legitimately licensed programmer can work with the product that 
> is rightfully his without stealing it. Not to mention that if 
> extracting binary was easy we'd all be doing it, and if we made 
> a tool to do it, then we'd be back to it being no different 
> than plaintext DI's which is I think what Walter was driving at.
>
> With respect to those who hold one ideology above others, 
> trying to impose those ideals on another is a great way to 
> ensure animosity. What a business does with their code is 
> entirely up to them, and I would guess that even Richard 
> Stallman himself would take issue with trying to impose an 
> ideology on another person. What does that mean for D 
> practically? Using a close-to-home example, imagine if Remedy 
> decided that shipping their ENTIRE codebase in .DI files with 
> the product would cause them to give away some new rendering 
> trick that they came up with that nobody else had. And they 
> decided that this was unacceptable. What would they most likely 
> do? Rewrite the project in C++ and tell the D community to 
> kindly pound sand.
>
> A license agreement is not enough to stop a thief. And once the 
> new trick makes it into the wild, as long as a competitor can 
> honestly say they had no idea how they got it (and they 
> probably really don't, as they saw it on a legitimate game 
> development website) the hands of the legal system are tied.
>
> I know there are those here who think that D can thrive without 
> the support of the corporates. But realistically, they are the 
> ones who dictate the languages most coders use and therefore 
> learn. THAT's what makes the Remedy thing so important. By 
> showing other corps that D is safe, reliable, and understands 
> THEIR needs, they will begin investing in training there 
> people, and so on. This pushes more people to learn D. Is your 
> goal the proliferation of D or the proliferation of ideology?
>
> And this idea that somehow because we lose CTFE, Inlining and 
> Auto support we should never allow DI's to be anything other 
> then full source distro's is borderline ridiculous. C++ 
> programmers are under ZERO illusions that inlining was ever 
> going to work when using third party libraries, so the idea 
> that some things won't work is beyond routine. They won't even 
> notice, much less care. I'll put it to you this way, when I was 
> considering D for our projects, I asked what features I would 
> lose in redacted DI files. My entire response to the list was 
> "That's it? Sweet! This thing still beats C++ six ways from 
> Sunday."
>
> Then I learned that the DI files weren't redacted. Now I have a 
> pull for it.


And as I referred in another thread, it is as not other languages 
don't support this, except maybe for CTFE. But even then it is 
mostly an implementation issue,
I think.

--
Paulo