clangupc / clang-upc

Clang UPC Front-End
https://clangupc.github.io/
Other
16 stars 5 forks source link

Clang UPC (and UPC2C) version string reflects the time of the build #43

Closed nenadv closed 10 years ago

nenadv commented 10 years ago

I noticed that we are using this cmake command to acquire the clang UPC version (tools/clang/CMakeLists.txt):

EXECUTE_PROCESS(COMMAND "date" "+%Y%m%d" OUTPUT_VARIABLE CLANG_UPC_VERSION)

This puts the current date into the Makefile and clang-upc will output:

clang version 3.4  (UPC 2014XXXX)

The date is the date of the build, when cmake ran, rather then the date of last commit.

Also, 'clang --version' should not report UPC in its version string. I think that the area in parentheses is reserved for OEM version (e.g. (Red Hat 4.7.2-8)).

The same is true for builds with configure/Makefile.

swatanabe commented 10 years ago

I can implement any formatting easily enough, as long as I know what you want.

nenadv commented 10 years ago

Installed clang on Fedora shows:

clang version 3.3 (tags/RELEASE_33/rc2)

RedHat must be patching the source code as the clang code contains the following to show the version number (tools/clang/lib/Basic/Version.cpp):

std::string getClangFullVersion() {                                             
  std::string buf;                                                              
  llvm::raw_string_ostream OS(buf);                                             
#ifdef CLANG_VENDOR                                                             
  OS << CLANG_VENDOR;                                                           
#endif                                                                          

  OS << "clang version " CLANG_VERSION_STRING " "                               
     << getClangFullRepositoryVersion();                                        

#ifdef CLANG_UPC_VERSION                                                        
  OS << " (UPC " CLANG_UPC_VERSION_STRING ")";                                  
#endif                                                                          

  // If vendor supplied, include the base LLVM version as well.                 
#ifdef CLANG_VENDOR                                                             
  OS << " (based on LLVM " << PACKAGE_VERSION << ")";                           
#endif                                                                          

  return OS.str();                                                              
}

CLANG_VENDOR is something that you can define when running cmake.

PHHargrove commented 10 years ago

Here is what Apple's /usr/bin/cc says:

$ cc --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
swatanabe commented 10 years ago

We have two basic choices for this. We can either say, "This is clang 3.4 and, by the way, it also has UPC support (version X)" or we can say, "This is clang-upc version X, which we built on clang 3.4." This needs to be resolved soon, so unless I'm told otherwise by Friday, I will implement it as:

$ clang --version
Clang UPC version 1.0 (based on clang 3.4)
...
nenadv commented 10 years ago

I would follow what we already have and match clang's version number:

clang version 3.4 (UPC 3.4.1 [DATE]) [optional vendor tag]

As Clang goes with two digits versions we should add one for UPC. I would keep a possibility for vendor tag that you can put on the command line as we might need to use it when we build a release.

3.4.1 should come out of some UPC_VERSION file inside the clang.

DATE should come out of some UPC_DATE file inside the clang. It is the date of last update in llvm/clang/upc2c and we need to establish a script to move the date. However, date should be there only for the development version that we build out of the development tree, but not in the released version. Maybe it can be conditional with the vendor tag? If vendor tag is present then no date as it is considered a release?

swatanabe commented 10 years ago

I don't really think it's a good idea to force CMake to re-run in every build.

nenadv commented 10 years ago

Not on every build, only when we change UPC_VERSION file.

swatanabe commented 10 years ago

On 03/25/2014 09:52 AM, Nenad Vukicevic wrote:

I would follow what we already have and match clang's version number:

clang version 3.4 (UPC 3.4.1 [DATE]) [optional vendor tag]

As Clang goes with two digits versions we should add one for UPC. I would keep a possibility for vendor tag that you can put on the command line as we might need to use it when we build a release.

3.4.1 should come out of some UPC_VERSION file inside the clang.

DATE should come out of some UPC_DATE file inside the clang. It is the date of last update in llvm/clang/upc2c and we need to establish a script to move the date. However, date should be there only for the development version that we build out of the development tree, but not in the released version. Maybe it can be conditional with the vendor tag? If vendor tag is present then no date as it is considered a release?

I'm not sure that the DATE is really useful. We only want it to appear for people working directly from the git repository rather than from a release. I would presume that this is mostly us, and for me personally, it's completely useless as I can just ask git for this information.

nenadv commented 10 years ago

With DATE we are trying to follow GUPC. However, note that in our case DATE is not just the git repository date, it is the max date from three repositories.