-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a -version flag to the PLFS tools #39
Comments
This only gets the svn version that it finds using plfs_get_svnversion.sh. Will that be good enough? |
No, that script returns some number from SVN. We want the PLFS version. See trunk/VERSION and versions/2.1/VERSIONS as examples. Talk to John B. and find out why he thought plfs.C's plfs_version returned what was in VERSION. Apparently it doesn't and I think it should. We're interested in the PLFS version, not the SVN version for the code library. |
Looking at the configure.ac I think that plfs_tag() is the function that returns the proper version information. I'll talk to John at the meeting tomorrow to make sure. |
So adding the version we want, namely the one we've been keeping track of in the VERSION file doesn't appear to be possible via SVN. At least not according to what I've been reading online. We can add the Rev number, but that won't give us the nice plfs version number we wanted. From what I've seen subversion doesn't keep track of tags in any meaningful way other than to make a copy of the directory. It looks like we can get the modify date with a little bit of work using svn propset, but that looks to be about all we can do. |
Thanks for looking into this TJ. Here's what I get when I run plfs_version: /users/brettk> plfs_version
mount: /plfs/scratch1
mount: /plfs/scratch2
I think it would be good to have the "-version" flag on the other binaries return: 2.1 (SVN exported, Built Oct 26 2011) and to have a plfs library function (in libplfs) called "get_plfs_version" (or something like that) that returns the same string to the caller. Let's keep the actual plfs_version application too as it yields information about the mount points on the system. Let's have you suggest the best way to do this at our next meeting. If it's using the VERSION file, fine. We need to document the things that must be done to generate a release and ensure the proper version gets set. |
Also, should we have the build create libplfs-2.1, for example instead of always libplfs? |
That way of doing the version option shouldn't be too difficult. Not sure about changing the libplfs name. It'll probably be fine if we add a symlink like libplfs -> libplfs-versionname, but I know virtually nothing about how that works so don't take my word for it. |
Alright, the version options have been added to the tools, let me know what you think. |
So, the -version option has been added and we have decided not to change the libplfs name to reflect the version information due to some complications with the mpi/io patch. Closing this ticket as of now. |
In the tools directory there are tools: plfs_check_config, plfs_flatten_index, plfs_map, plfs_query, plfs_recover, and plfs_version.
Each of these tools needs a -version (or --version, depending on how flags are done with plfs tools now) flag that returns the version of the product. There's a utility plfs_version that calls plfs_version in plfs.C.
With this done, anyone that uses a tool can see what version of the product they are using. Also, any code can call plfs_version in plfs.C to find out what the version is.
The text was updated successfully, but these errors were encountered: