Include necessary parts of StdHEP in the distribution

[kilian]

Compiling and linking StdHEP is a real pain. Now that the source is no longer maintained, we might just include it in the WHIZARD distribution (permission assumed). Just make sure that it works with all our favorite compilers 3:)

TODO: automatically configure Makefiles, force shared and/or static libs to be built and paths set, submit dummies for unresolved symbols in StdHEP.

Since the version is frozen, it should be no problem if StdHEP is also adopted by the LC generator group.

[Juergen Reuter]

Here are my remarks on this: yes, JRR is willing to do that, the code should end up in $(srcdir)/stdhep as this is external code, as there is no speed penalty I would make a compilation without StdHep? impossible (the risk of any conflicts from externally installed StdHep?'s is tiny). But, this would make it also impossible to include user/private versions of StdHep?. Is this ok? Shall we ask the LC generator group on that point? JRR would put FMCFIO and StdHep? into one library, libWO_stdhep.la potentially. Agreed? JRR will check whether the code should remain as .f or could/should be transferred to .f90. Opinions on that point? General remarks?

[Juergen Reuter]

Asked the LC generator group whether they would be concerned with our policy to exclude external StdHep? to be linked. Waiting for answer, as well as for the comments to my comments from our team.

[kilian]

WK: agree, the hard part is to make StdHEP compile and link under all circumstances (test w/ and w/o static enabled, test w/ all compilers).

The dummy interface could be trashed then, also the STDHEP flag in the test dir and the conditional flag in the StdHEP tests, also the STDHEP_DIR and FCMCFIO_DIR environment vars.

(If there was an option to link an external build, it would become a --with-stdhep option. The changed path would be communicated to configure. However, if StdHEP really stays frozen, there is probably no need to do this, since the files are supposed to be completely portable.)

A bonus could be that we could make use of the XDR library that comes with StdHEP, to make our own raw event files portable across platforms.

[Juergen Reuter]

JRR does have a fully working autotoolized version of StdHep? that is working with ifort, nagfor and gfortran. Shall I commit? (with all caveats: StdHep? is always possible, external StdHep? linking has been abandoned)

[kilian]

Yes, go ahead.

Did you check (or write a test) with a static stand-alone executable?

[Juergen Reuter]

Good point, now added a static_2 test that generates stdhep events. Works. Only the necessary files of Stdhep are included, all the special files for Herwig, Pythia, Jetset, Madgraph etc. are excluded. Closing. (In case of problems please reopen).