[eg] deprecate cfortran and Hepevt headers and announce mv to ROOT/

[ferdymercury]

It's urgent to avoid a sure collision with Debian when doing make install

libcfitsio-dev installs cfortran.h on the same destination as ROOT.

fyi @agheata

[pcanal]

I understand the challenge with cfortran.h being duplicated across product.

That said, Hepevt.h is part of the TGenerator interface and defined/declare the default layout a fortran implemented generator can/should use to leverage the default implementation available within TGenerator.

So this PR (underlying feature) is not a technical/straight-forward cleanup but rather a real feature deprecation: "no longer supporting Fortran based generator".

So this deserve a larger discussion and the conclusion might be to recommend this PR, to delay this PR or to expand this PR to deprecate a larger set of functionality.

[ferdymercury]

That said, Hepevt.h is part of the TGenerator interface

Why so?

It's only used by TGenerator.cxx but not by TGenerator.h

Or you mean someone was using

#include "TGenerator.h"
#include "Hepevt.h"

directly in some downstream code? and then binding those in some way ?

[pcanal]

directly in some downstream code? and then binding those in some way ?

yes (via the 'magic' of common blocks)

Per the documentation:

If the generator code stores event data in the /HEPEVT/ common block 
Then the default implementation of ImportParticles should suffice.   
The common block /HEPEVT/ is structed like                           
                                                                     
\verbatim
  // C                                                            
  typedef struct {                                                   
     Int_t    nevhep;           // Event number                      
     Int_t    nhep;             // # of particles                    
     Int_t    isthep[4000];     // Status flag of i'th particle      
     Int_t    idhep[4000];      // PDG # of particle                 
     Int_t    jmohep[4000][2];  // 1st & 2nd mother particle #       
     Int_t    jdahep[4000][2];  // 1st & 2nd daughter particle #     
     Double_t phep[4000][5];    // 4-momentum and 1 word             
     Double_t vhep[4000][4];    // 4-position of production          
  } HEPEVT_DEF;                                                      
                                                                     
                                                                     
  C Fortran                                                          
        COMMON/HEPEVT/NEVHEP,NHEP,ISTHEP(4000),IDHEP(4000),          
      +    JMOHEP(2,4000),JDAHEP(2,4000),PHEP(5,4000),VHEP(4,4000)   
        INTEGER NEVHEP,NHEP,ISTHEP,IDHEP,JMOHEP,JDAHEP               
        DOUBLE PRECISION PHEP,VHEP                                   
\endverbatim

[ferdymercury]

yes (via the 'magic' of common blocks)

wouldn't it make then more sense to copy-paste HepEvt.h into TGenerator.h rather than having a separate header? And then remove HepEvt.h Otherwise it can also be 'magically' broken if only includes TGenerator.h, right?

[github-actions]

Test Results

    24 files      24 suites   4d 3h 22m 0s ⏱️
 3 886 tests  3 881 ✅ 0 💤 5 ❌
83 177 runs  83 172 ✅ 0 💤 5 ❌

For more details on these failures, see this check.

Results for commit a54ae4a.

♻️ This comment has been updated with latest results.

[pcanal]

wouldn't it make then more sense to copy-paste HepEvt.h into TGenerator.h rather than having a separate header? And then remove HepEvt.h Otherwise it can also be 'magically' broken if only includes TGenerator.h, right?

No more than any other loosely coupled entities ... They are not always use in concert, so it also make sense to keep them separated (eg. HepEvt.h could be use for a C compilation unit defining the generator function).

[ferdymercury]

Would it be then ok to directly move the header to ROOT/cfortran.h and ROOT/Hepevt.h? To avoid collision with cfortran.h installed by libcfitsio-dev, as a workaround while you decide if this feature may be deprecated or not?

[ferdymercury]

Probably also fixes #20700 if we fully deprecate it.

[ferdymercury]

Failures seem unrelated.

[pcanal]

Would it be then ok to directly move the header to ROOT/cfortran.h and ROOT/Hepevt.h? To avoid collision with cfortran.h installed by libcfitsio-dev, as a workaround while you decide if this feature may be deprecated or not?

I think this is a fair compromise.

[ferdymercury]

Failures seem unrelated.

Can someone maybe restart Windows build?

[ferdymercury]

remaining Ubu failure is unrelated