done myself in cws tempdir

.

I don't consider this fixed by just silencing it.

The whole section doesn't make much sense to me.
the $(eq,$(var),$(NULL) ...) is silly as well, since dmake has a dedicated check
for null.
But even that is not necessary, since there is the *= (i.e. only do the
assignment, if there is no value yet)

Really: If you add so magic, you're not even convinced yourself of (ref the TODO
-comment): At least add what is intended with that mess.

concrete: Why strip? Why the echo? Why the multiple assignments to LOCALIZESDF
with forced silencing of errors? I mean if you use !, you need to have good
reason (and should state it).
When adding such "monsters", you really ought to add a comment as to why those
quirks are used, and why the straightforward way cannot be used/is not suitable.

And wrt commented-out code: If you only comment it out, you can as well just
delete it. Version-control history can bring it back. If there is a reason to
keep it in the file itself: justify in a comment. But a reference to the concept
along with a pointer to the file's history would be far more useful IMHO

Reopen, assign to ihi to answer the above.

reopen and reassign needs to be two steps.
@ihi, please see last comment.

.

since that "monster" was created by me, i should comment (and even more, i
should have commented the source...)

- the whole block is meant to locate localize.sdf files.

- *= won't work here as

aaa:=
aaa*:=ttt

still leaves $(AAA) empty

-$(null ... ) might have been an option but i actually don't remember anymore
why using $(eq ... ) instead. this cws (and his predecessors) got a kind of
weird history...

Yes, of course when using *=, you must not use it to assign the empty value
before, but you can use $(assign ...) in a condition for example.

But that is only the minor part of the problem.

> the whole block is meant to locate localize.sdf files.

That's the first point of confusion: Why do you have to locate them in the first
place? My understanding is that the one-file-per-language sdfs are split up to
the individual project/module's chunks as they were in the source before the
reorganization.

But even when you have to check multiple locations: Why with strip echo/IFEXIST
stuff? That is the more interesting question.

If it is either in that place, or in the other place, then a percent-rule would
also be an option, wouldn't it?
 

cloph: I agree that there is a bug underlying that and it needs to be fixed.
File a new issue for this please.

This issue specifically was filed for the displaying of the "Executing shell
macro..." thing, and that *is* fixed.

-> FIXED again

reopen as discussed on IRC (options are either: use another QA rep to approve
this "fix" or to remove the issue from the associated cws, both are not
considered) so still waiting for a proper fix/answers to the questions

cloph: ok, simply to get the more important T(E)MP fix in I'll remove this issue
from the cws. Happy now? (I'll NOT remove the @, though)

i'll rewrite the block with less magic and more comments

Created attachment 63893 [details]
doing the required bits with less magic - still reuires more testing...

Created attachment 63931 [details]
back to even more magic. specific lokcalize.sdf or according .zip may not exist at all

xthrobber.src in toolkit is an example of that

I'm adding this comment to all open issues with Issue Type == PATCH.  We have 220 such issues, many of them quite old.  I apologize for that.  

We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0.

If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know.

On the other hand, if the patch is no longer relevant, please let us know that as well.

If you have any general questions or want to discuss this further, please send a note to our dev mailing list:  dev@openoffice.apache.org

Thanks!

-Rob