make -j mysterious race condition on user_str.... tests

[Juergen Reuter]

user strfun test failing..... There is a strange race condition.... probably the library is not completely loaded... I dont know. Giving up for now, have to live with that bogus.

[Juergen Reuter]

This is getting on our nerves and triggers Jenkins too often....

[kilian]

I haven't looked at the output, but thinking about it, it probably originates from the fact that both user_cuts and user_strfun build the library user.la, although the source code file names differ. This obviously can lead to a race condition.

Now, this has likely zero impact for the user, even if he uses make -j. It is only a problem of the testsuite.

Three ways out:

(1) allow for a custom name for the user library, (2) inhibit parallel execution for this part of the testsuite, (3) merge user_cuts and user_strfun again.

(3) is probably the simplest solution, with the slight caveat that it is broken under gfortran 4.5. (1) is preferable on general grounds.

[kilian]

BTW, this actually belongs to a Tracker category "testsuite" which we might add ...

[Juergen Reuter]

I thought about that, too, that it is somehow a problem with user.la needed by both of them. So I made them dependent one on the other. The problem was still there...

[Juergen Reuter]

Funny thing: I could not reproduce this with make check, only make distcheck triggered it...

[Juergen Reuter]

I tried to reproduce this, but I failed... 10 tries in make check, 10 in make distcheck, one in make extra-distcheck did not fail.

[Juergen Reuter]

I think I might have a solution, testing....

[kilian]

Sorry, I'm also working on this right now ... implemented --user-target as option to avoid clashing user.la

Also testing right now - what's your idea?

[Juergen Reuter]

Ah fk.... thats again additional code... No, no, no, simply make the tests conditional, have to check.... again, some wasted time...

[kilian]

Well, the option --user-target works as intended, and might be useful anyway. Since it's done, I check it in nevertheless ...

[Juergen Reuter]

Ok, my solution is void then...