Re: GNAT GPL is not shareware

["Björn Lundin" <b.f.lundin@gmail.com>]

Ok, I need to reply to this rubbish

On 2015-01-07 17:32, Shark8 wrote:
> On 07-Jan-15 04:00, Björn Lundin wrote:
>> On 2015-01-06 22:46, Shark8 wrote:
>>>
>>> No, because it still contains [and relies upon] "Example.Parent.Child"
>>> which has had its own dependencies removed.
>>
>> So ? How would a db solution stop that?
>>
>> "delete from sources where name like 'Example.Parent%'"
>> would have the same effect.
> 
> Why would you have the fully-qualified name stored as text?
> It makes far more sense to break the name into an actual structure
> itself, in order to show its "lineage"; and once you do that your
> example simply doesn't work.

It does not matter HOW you represent it.
A db can be manipulated, get corrupt, just as a file system.


> Again, you're showing that you're thinking of everything in terms of
> text, not in terms of meaningful structure.

No, but since I don't know your model, I
visualized with something simple.



>> however, in a filesystem (with say svn) I could
>>
>> svn stat - to see that  Example.Parent.ad? is missing
>> svn revert  Example.Parent.ad?
>>
>> and I would have restored it.
> 
> Showing that you could easily recover from accidentally entering an
> inconsistent state is *not* the same as preventing the state-change to
> inconsistency in the first place. -- Here is an example of early
> development using databases as a form of both version-control and
> project-management:
> https://drive.google.com/file/d/0BwQVNNshW39cTXVOdWxQaVJ5WjA/edit

I see nothing in there to _prove_ that a code-base cannot be
inconsistent in a db - regardless of the db model. That is your claim.


>>>> How do you do for accomplish linking out-of-date objects ?
>>>> You seem really hung up on this, so I interpret it as it happens often.
>>>> Does it?
>>> I've only had it happen a couple times.
>>> That it can happen at all, when it is preventable, is the issue.

I guess this did not happen with Gnat. See below


>> and exactly _how_ is this more preventable with a db solution?
> Because with a DB-system you can guarantee that the "system" is not
> inconsistent or out-of date; and you can associate generated objects
> with exactly the state that generates them.

Gnat calls that state ali-files...

<http://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn_7.html#SEC84>
That is gnat user guide , chapter 6.5
§4

"The ability of GNAT to compile in any order is critical in allowing an
order of compilation to be chosen that guarantees that gnatmake will
recompute a correct set of new dependencies if necessary. "

Seems to me that ACT already can guarantee this with files.
Yes, they use the word guarantee.

And using gnat since 2002 at work,
I've never even heard of this happening with gnat.

However, I do recall something with ObjectAda 7.2
If changing source files belonging both to a certain
ada-lib AND its parent lib, the source belonging to the parent lib was
not recompiled.
However, this was 10+ years ago, and I only remember i vaguely,
so it might have been something completely different.


>> And I still do not see why changing PATH to point to different
>> compiler installations are considered DISGUSTING
> 
> Because it is changing a fundamental behavior in a completely
> invisible-to-the-build-system manner; 

Yes, fully transparent.
Easy to deploy, easy to reconfigure, easy to understand.
All three reasons are good for maintenance.

> as someone pointed out you can use
> make-files to set the path but this is a work-around -- instead of
> "making it a variable of the function" it's "depending on a global
> variable" -- instead of making the build-system analogous to a "pure
> unit", it depends on state.

So ? The state is controlled.
You are building vapor-ware.

--
Björn