Can we clean the clutter

[zack-vii]

The repo is pretty big and its hard to tell whats used and whats still there for historical reasons.

I propose we gather the code and reorganize the folder layout a bit.. i.e. API related stuff into one folder .. one folder for 1to1 files . e.g.

• mdspus.sh, mdsplus.csh,and stuff together with the content of rpm.

• idl stuff togethser in one folder.

• device stuff (mitdevices, camshr, remshr) into ./devices

• tcl, ccl into mdsdcl

• Kbsidevices contains binaries (?) and java files that are not referenced anywhere but the change logs?

• Then there is #2014.

• manpages, docs, ?

We could then order the build of the modules according to core, core-tests, apis (cpp, idl, java, hdf5 etc), api-tests, devices, docs

Folder structure might as well be

README.md # consolidate README.INSTALL and maybe README.JENKINS.md
conf/
  clang-format # available thru 'make clang'
  (all make stuff, bootstrap, generators automake autoconfig scripts, suppressions)
m4/
configure.m4
Makefile.in
Makefile.inc.in
aclocal.m4
deploy/
include/ # public, API we want to keep intact
_include/ # private but shared, e.g. pthread_port.h, API that may change
core/
  libs/
    mdsshr/
    tdishr/
    mdsipshr/
    mdsdcl/
    ...
  bins/
    actions/
    tdic/
    tditest/
    setevent/
    wfevent/
  tdi/
    *.tdi
  xml/
  os/
    win/
      setJDK_DIR.bat
      icons/
        *.ico
    linux/
      desktop/
      icons/
        $pixmaps
      install/ # (./rpm)
        envsyms.in
        setup.sh
        setup.csh
    macosx/
  misc/
    sites.csv
    mdsplus.jpg
    mdsplus_logo.jpg
apis/
  cpp/
  java/
    java/
      jscope/
      jtraerser/
      ...
    libs/
      mdsjava
      ...
   matlab/
      matlab/
        *.m
   php/
   idl/
     idl/
       *.pro
     libs/
       mdsip/ # former mdslibidl
       mdsevent/ # former idlmdsevent
       mdswidgets/ # former idlmdswidgets
  sql/
  hdf5/
  epics/
  jsnode/
  labview/
    labview/
      MDSplus/
      *.lv
    libs/
      mdsobjects/
  roam/ # ?
devices/
  support/ # former ./device_support/
  d3dshr/ # ?
  camshr/
  ramshr/
  mitdevices/
  pydevices/
  mdsvme/
docs/
examples/
testing/
.gitignore
.gitattributes
.gitmodules
.clang-format

remove

ntwdblib.dll
ntwdblib.lib
scripts/
devscripts/
mdsobjects/labview/MDSplus_LV2012 # zip it and make it available for download on mdsplus.org/dist/LabView
mdsobjects/labview/MDSplus_LV2015 # zip it and make it available for download on mdsplus.org/dist/LabView
updatepkg.log

[zack-vii]

Please leave your opinions. =)

[WhoBrokeTheBuild]

The idea of structuring them based on the packages is very attractive I don't like the core/ folder on its own, and the plural of bins and libs is a bit awkward I think it's okay to have the main libraries at the root level, but the APIs and language specific tool should absolutely be in a sub directory

I use a structure borrowed from Unreal Engine for my personal projects, where we ditch "source" and "include" in favor of "Public " and "Private" https://github.com/WhoBrokeTheBuild/Dusk/tree/master/Modules/OpenGL That could be worth considering

[alkhwarizmi]

Dear zack-vii ,

I think reorganisation already took place few years ago, but good software undergoes such restructuration periodically and I am in favour of it and glad that you are willing to embark in such a delicate and time-consuming job.

Regarding the above structure I can tell that it is almost exactly like I would do it myself. I am one of those that places the s at the end of variables to indicate a list or vector and bins/, libs/ do not seem wired to me. This is a bit less true for apis/ but it follows the logic and I am not against it. I used connectors/ recently but in this case apis/ is maybe more appropriate. Also I use myself core/. Not so clear what is deploy for, but I guess it cannot be removed.

Finally, I have a question and a comment.

Question: who is currently maintaining the LabView API?

Comment, not really regarding the folder structure but where the installer places the MDS+ libraries: I have recently found myself in this condition. Briefly, the fact that MDS+ installs its libraries in the Windows32 (or WOW64) folder is causing other tools, e.g. the OpenModelica simulation software, to break. I am sure the decision of installing in system folders was not taken without reasons, but you may want to think about it. Nowadays, it could be better to install dependencies within the program installation folder and rely on auto-created environments at the tools level.

Sincerely,

[zack-vii]

Nowadays, it could be better to install dependencies within the program installation folder and rely on auto-created environments at the tools level.

I am happy to inform that since a while MDSplus can be installed on user level. this will place all files ina folder of your choise and set up evironment variables so the can be used ootb. for a multiuser system you may however move those env to system so it will hold for all users.