Consolidate file locations

[tunnell]

When trying to make programs that use the nest library, an issue I encounter is the sporadic location of where header files are located. Can we do the following:

• G4 bindings move into a new repository
• Examples in their own folder
• NEST and VDetector header in same location
• NEST and VDetector source files in same location

[mszydagis]

• Not moving G4 bindings into a new repo. Sub-folder good enough. I don't want to manage a separate repo that needs the NEST repo called separately.
• Examples are already in their own folder (Tools). I don't want more sub-folders, I like the way it is now.
• Talk to Jacob. This will annoy people on LUX and LZ again as yet another file location change. There is reason for it though with Detectors as a separate subfolder. This would require not only moving files but also re-writing README instructions on how to implement a new detector.
• Talk to Jacob. This will annoy people on LUX and LZ again as yet another file location change.

[tunnell]

We can ask Jacob. I just meant testSpectra and Testnest

[jpbrodsky]

Chris, are you installing NEST properly? If you do that, you should end up with a single folder with NEST headers in the install directory.

…

________________________________ From: Chris Tunnell <notifications@github.com> Sent: Sunday, July 8, 2018 1:59:21 PM To: NESTCollaboration/nest Cc: Subscribed Subject: Re: [NESTCollaboration/nest] Consolidate file locations (#6) We can ask Jacob. I just meant testSpectra and Testnest — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#6 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMIhA4APAJU0enjCJrQHuUf8rDQQUjo5ks5uEnKpgaJpZM4VG1YN>.

[mszydagis]

Actually, Jason, I fear you are behind the times by several weeks. The headers have been moved around by Jacob and/or myself recently.

[jpbrodsky]

After a make install, all the headers, regardless of where they are located in the source code, should be copied over the to "include" directory in the installation directory. I just tested this with a fresh install. However, I spotted another issue in the process: README_Setup suggests installing NEST into the build directory. I don't recommend that, and can't get it to work with the current code. The readme should instead instruct you to create a separate install directory, point to it with CMAKE_INSTALL_PREFIX, and then your NEST will be installed there when you "make install". This is a generally good idea for a number of reasons, among them that the installed version won't be broken every time you try to compile a new version. Best, Jason

…

________________________________ From: mszydagis <notifications@github.com> Sent: Sunday, July 8, 2018 7:21:03 PM To: NESTCollaboration/nest Cc: Brodsky, Jason Philip; Comment Subject: Re: [NESTCollaboration/nest] Consolidate file locations (#6) Actually, Jason, I fear you are behind the times by several weeks. The headers have been moved around by Jacob and/or myself recently. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#6 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMIhA-Ek71_ilpt05yGxwI5WxDmRdCxzks5uEr4PgaJpZM4VG1YN>.

[tunnell]

@jpbrodsky I meant the file locations within the repository. In this case, all the source and header files are spread out a bit. You're right that if somebody is just linking to the library, then after install, you have the headers in one place. I guess I should have been more clear: some ways that you can bind other languages to C++ require some sort of reflection so you know where all of the headers and cpp files are such that they can be 'patched' with the binding description (https://github.com/NESTCollaboration/nestpy). At least the way people recommended it to me, you ship the raw code with the bindings and let it compile during pip install if no prebuilt binary exists for your setup.

The whole issue is not that big a deal (can skip this release or completely). My impression just of the repository itself was that the code locations felt nonstandard to me, but it's been a while since I've done any heavy C++ programming.

On the install location, do you want to make a quick pull request with the change about the install instructions?

[jpbrodsky]

There may be a way to cmakeify making those bindings so that they know where the various headers are from the cmakelists. That doesn't make the header locations logical, but it makes the logic of the header locations not anyone's problem except whoever maintaining the cmakelists, which is mostly me with some help from Jacob. I'll take care of the readme change in the morning.

…

________________________________ From: Chris Tunnell <notifications@github.com> Sent: Sunday, July 8, 2018 11:48:15 PM To: NESTCollaboration/nest Cc: Brodsky, Jason Philip; Mention Subject: Re: [NESTCollaboration/nest] Consolidate file locations (#6) @jpbrodsky<https://github.com/jpbrodsky> I meant the file locations within the repository. In this case, all the source and header files are spread out a bit. You're right that if somebody is just linking to the library, then after install, you have the headers in one place. I guess I should have been more clear: some ways that you can bind other languages to C++ require some sort of reflection so you know where all of the headers and cpp files are such that they can be 'patched' with the binding description (https://github.com/NESTCollaboration/nestpy). At least the way people recommended it to me, you ship the raw code with the bindings and let it compile during pip install if no prebuilt binary exists for your setup. The whole issue is not that big a deal (can skip this release or completely). My impression just of the repository itself was that the code locations felt nonstandard to me, but it's been a while since I've done any heavy C++ programming. On the install location, do you want to make a quick pull request with the change about the install instructions? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#6 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMIhA3jeex3V93j20lvz0f4ldeN_08z_ks5uEvyvgaJpZM4VG1YN>.

[tunnell]

Closed by #11

[tunnell]

The changes would be:

• Rename Tools to examples

• Create src

• testNEST.cpp -> Tools/

• testSpectra.cpp -> Tools/

• Detectors/DetectorExample_XENON10.hh -> include

• Detectors/VDetector.hh.hh -> include

• NEST.cpp -> src

• G4integration/ -> examples

• Delete empty Detectors

Worth proposing here since it might require people binding to NEST to make changes. And we'd want to do this once perfectly. @jpbrodsky @mszydagis

[jpbrodsky]

I'd suggest not moving the G4Integration folder, or at least not calling it an example.

The G4 integration code is not intended to be user-modifiable in the way an example should be. Users of the integration should use the classes provided in their G4 code, rather than trying to copy those classes into their project to modify them. This is because the logic required to pipe G4 tracks through the NEST model is complex and has tons of fiddly cases that break easily.

The G4 integration code is also not a ready-to-run example. It requires an existing G4 Monte Carlo to be added into.

[mszydagis]

@tunnell I have collected solid feedback from everyone. And we would like to make the following modifications to your plan. I have composed an average compromise over everyone's ideas:

Rename Tools to examples: OK

Create src: OK

testNEST.cpp -> Tools/ No, into src instead please.

testSpectra.cpp -> Tools/ Is this a typo?? Did you mean into examples/ since renamed above?

Detectors/DetectorExample_XENON10.hh -> include Not quite: include/Detector

Detectors/VDetector.hh -> include: Again: include/Detector

NEST.cpp -> src: OK

G4integration/ -> examples: @jpbrodsky had said please no, so let's respect that.

Delete empty Detectors -- see above: preserve as its own subdirectory.

One more request, from LZ software expert L. Kreczko: include/*.hh -> include/NEST/ (so, then detector stuff will be in include/Detector in parallel, thus include folder itself will now be empty)

I can speak for LUX and LZ, and if Jason can speak for EXO-200/nEXO and you Chris for XENON1T/nT then all stakeholders have agreed. Please proceed and prepare these changes. Everyone agreed though: never again :) So, it's a case of speak now or forever hold peace..