[Dune] [#771] configure generated gridtype.hh / dgfgridtype.hh (Attachment added)

[Dune]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#771 - configure generated gridtype.hh / dgfgridtype.hh
User who did this - Robert Klöfkorn (robertk)

----------
@Oliver: Why are you worried about the maintance, we will do it (as before). What do you mean with doing it right? The generated code compiles and works as it should, and is still human readable. What more do you want? Maybe you have to get a bit more specific. 

@Christian: 
> The main reason why I rejected the request for merge was, that it isn't working.
I never asked for a merge. It seems to me that you didn't even look at the patch. The patch I send was to add a compatibility m4 script generating the headers gridtype.hh and dgfgridtype.hh witch will simply forward to the old locations. Nothing special here. I added a new patch only containing the m4 script, which will be sufficient for us. It will not affect the "stability" of the release in any way.

I just checked, the grid-howto works and I removed the last warnings. If the howto didn't work three weeks ago there might have been other reasons for not that.

> Up to now the hack was limited to small part of the repository. 
That is still valid with the new solution, as you can see (still only two files, or old ones are deprecated).
By the way I'd rather like to call it a solution to a problem than a hack. For a hack there are always better solutions available that have been avoided because of time issues. I don't see a better solution here, otherwise it would have been implemented. 

> It was always agreed that it isn't part of the interface. 
That is still valid with the new solution. Nobody is forced to use this. 

> But now after the latest changes all implementations have to provide their own part of the magic.
??? There is only one part for all grids. I don't understand why you think all implementations have to provide thier own part. It's one part for all. 

> There are certain things which are not possible with the current approach, especially it is not possible to
> define different grids.
It was never intended to do that. You can come up with a solution that does it. Feel free. 
I think several people will be interested, including myself. 

> I do like the idea of easy exchangeable grids, but I get the impression that this hack starts growing in 
> complexity and when a hack is getting mroe complex, it requires reconsideration
Complexity was just decreased by puting all the good stuff to only one place. Thanks to Martin at this point.

>  perhaps there is a better solution to the problem.
> I'd like to have solution, where you can easily change the grid but not by means of preprocessor magic.
> Perhaps it is possible to introduce this switch on the C++ level and thus allow different ways of changing 
> the grid.
Until you have found such a solutiopn we can live with the current solution. This way you'll have time to think about this problem and we can carry on with our work. It's a win-win situation.

> You imply that your changes and the centralization are an improvement. That is exactly what I doubt.
If you read carefully my and Martins comments above there are reasons why we consider this changes to be an improvement. Up to now you have not explained why this is not the case (just mentioning `it's not` does not prove anything). The only thing you made pretty clear is that you don't like our solution. Can't help with that one, sorry. As you are not forced to use it, you'll get over it or invent something better.
Again, a win-win situation. 
----------

One or more files have been attached.

More information can be found at the following URL:
http://www.dune-project.org/flyspray/index.php?do=details&task_id=771#comment1900

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.