search

SegmentLinking / cmssw

CMS Offline Software
http://cms-sw.github.io/
Apache License 2.0
1 stars 1 forks source link

Standalone fixes #33

Closed ariostas closed 3 weeks ago

ariostas commented 3 weeks ago

This PR fixes a couple of things on the standalone version. It fixes the setup script and makefiles so that it can be built in standalone mode without any extra steps. It also fixes an issue with the ROOT file that the standalone version creates since it saves the git logs, but the logs of the CMSSW repo are too large now, so they are now truncated to the 100 latest commits.

VourMa commented 3 weeks ago

Quick question: Is this to be integrated in the current open PR to cms-sw, or to be included post-merging of that PR? Mostly asking so that I know if we should have this branch as the one where we push and review all of the updates to go in the main PR. If this is the case, a rebase is needed, so that we have workflows for easy testing.

slava77 commented 3 weeks ago

this branch

@VourMa do you mean LSTCore_standalone_fixes ? the name alone is already suggestive it's not a generic branch to batch-integrate what is intended to go to CMSSW_14_1_0_pre3_LST_X_LSTCore_realfiles (the cmssw PR branch)

slava77 commented 3 weeks ago

should we make some generically named, e.g. CMSSW_14_1_0_pre3_LST_X_LSTCore_realfiles_integration to accumulate the contributions before injecting to the cms-sw PR branch?

VourMa commented 3 weeks ago

should we make some generically named, e.g. CMSSW_14_1_0_pre3_LST_X_LSTCore_realfiles_integration to accumulate the contributions before injecting to the cms-sw PR branch?

I am trying to make one along with the fix for the directories but I am facing some unexpected problems in compilation (that are not even connected to our updates). It should appear today however, one way or the other.

slava77 commented 3 weeks ago

looking at the commit history, do I understand correctly that our "merge base" is CMSSW_14_1_X_2024-05-31-2300 (the explicit diff seems to agree)?

Just to be sure where to start the test build updates.

ariostas commented 3 weeks ago

looking at the commit history, do I understand correctly that our "merge base" is CMSSW_14_1_X_2024-05-31-2300 (the explicit diff seems to agree)?

Sorry, I should have stuck with 14_1_0_pre3. Manos mentioned that we have to be careful since some files don't match pre3. I'm not sure it it's worth force-pushing to rebase with pre3 or just work with this for now.

slava77 commented 3 weeks ago

since it's quite likely that the integration will take some time, it will be inconvenient to work with an IB (unless we are forced to do it). So, if 14_1_0_pre3 still works for all our files, let's get back to that. THe more recent option is pre4, which was made available last week.

ariostas commented 3 weeks ago

Okay, so let's create CMSSW_14_1_0_pre3_LST_X_LSTCore_realfiles_integration (with true pre3 (or pre4) files) and we'll submit our PRs there. Then next time there's a reasonable batch of updates we'll (possibly squash and) force-push to CMSSW_14_1_0_pre3_LST_X_LSTCore_realfiles.