move get_*.sh scripts to top-level subdirectory "wmo_scripts"

[edwardhartnett]

We can move these scripts out of our source code directory.

The scripts need to be modified to work from the new location.

[webisu]

The name "wmo_scripts" is not very descriptive. Many of the scripts read from the NCEP, ECMWF, DWD web sites. One script is for updating fnlist.c, fnlist.h. Updating these two files should not be done by hand. The *.sh files are for developers only, so they do not have to be portable. The scripts need to be run from specific directories. If you run the script that reads the ECMWF grib names in the NCEP directory, then you will replace all the NCEP grib names by ECMWF grib names. If you don't want users to run the *.sh files, just chmod them to 644. Some files need to be updated by hand, and some are updated by *.sh programs that read for the relevant web site. Having the *.sh in the same directory in the *.c directory makes it easy to figure out whether you update the table by hand or by script. Putting the *.sh files in a separate directory makes it more difficult to determine whether a *.sh exists. (More *.sh names to consider.) Most software projects have scripts that read from external web sites that create code fragments. Very few projects have a plug-n-play interface which wgrib2 has for its options. You can add an option by adding a file to the wgrib2 directory, and run "make". You can delete an option that is not called by another option or normal code by simply deleting the file. To do that, you need scripts that maintain the list of available options.

…

On Mon, Jul 22, 2024 at 9:20 AM Edward Hartnett ***@***.***> wrote: We can move these scripts out of our source code directory. The scripts need to be modified to work from the new location. — Reply to this email directly, view it on GitHub <#210>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIB7ZS4LNKWYUHVZWY6JVDZNUBIDAVCNFSM6AAAAABLIJ7ZY6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGQZDEOBWGU4DQNY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[edwardhartnett]

I'm afraid that method of using plugins will no longer work.

If you add a file to a CMake built directory and run make, it will make no difference. The file will be ignored if it is not in the CMakeLists.txt file. Nor will the user be able to turn off options by deleting code files. All build options have to be specifically handled in cmake.

Many programs and libraries have plugins, including netCDF and HDF5. The way they do it is to require .so files which they dynamically link to and then they call functions of predefined API. So to use a plugin you do not have to (re)compile the whole library, just the plugin.

We can transition to this if you want to keep your plugin architecture. It would not be hard. Then the plugins can also be in a separate directory, or just exist in user-space, if it's a user-built plugin.

[webisu]

I realize that you need to alter the CMakeLists.txt. However, the API is pretty dynamic. Nearly every release changes it.

…

On Mon, Jul 22, 2024 at 10:19 AM Edward Hartnett ***@***.***> wrote: I'm afraid that method of using plugins will no longer work. If you add a file to a CMake built directory and run make, it will make no difference. The file will be ignored if it is not in the CMakeLists.txt file. Nor will the user be able to turn off options by deleting code files. All build options have to be specifically handled in cmake. Many programs and libraries have plugins, including netCDF and HDF5. The way they do it is to require .so files which they dynamically link to and then they call functions of predefined API. So to use a plugin you do not have to (re)compile the whole library, just the plugin. We can transition to this if you want to keep your plugin architecture. It would not be hard. Then the plugins can also be in a separate directory, or just exist in user-space, if it's a user-built plugin. — Reply to this email directly, view it on GitHub <#210 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIB7ZQ6MKQNFEZENRJX6TLZNUIGZAVCNFSM6AAAAABLIJ7ZY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBTGA4DCOJSHE> . You are receiving this because you commented.Message ID: ***@***.***>

[edwardhartnett]

Let's discuss that under another issue, which I will start.

The point of this issue is to move the get_*.sh scripts to their own directory away from the source code. THe scripts will have to be modified to find the files from the new location, but this should be easy.

The options scripts can be handled separately.