Skip to content
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

How to set kRootDir for FlagValue::CleanName #86

Closed
schuhschuh opened this issue Mar 24, 2015 · 7 comments
Closed

How to set kRootDir for FlagValue::CleanName #86

schuhschuh opened this issue Mar 24, 2015 · 7 comments
Assignees
Milestone

Comments

@schuhschuh
Copy link
Member

Original issue 75 created by schuhschuh on 2014-03-20T16:12:02.000Z:

The kRootDir is a static variable in the body of the CleanName function which strips of a common path prefix from all C++ module file paths. I am wondering how this static variable can be overridden by a global variable.

@dreamer-dead
Copy link
Contributor

Could you explain, what is it for?
As I see, kRootDir is a substring that should be contained in file paths.
Filenames obtained via __FILE__ macro, so kRootDir should be a variable which is known at compile-time.
Am I right?
Can it be configured by a CMake variable?

@schuhschuh
Copy link
Member Author

Well, I am not so clear about it's purpose myself. From what I could tell, it is not possible to actually set this variable neither at runtime nor compile time of a client program. If I remember correctly, I've opened this issue myself to look into it some day and possibly come up with a way that a project that uses gflags can specify/modify the value of this variable in the main function.

@schuhschuh
Copy link
Member Author

Is it possible to do something like this:

extern gflags::CommandLineFlag::CleanFileName::kRootDir;

int main()
{
  gflags::CommandLineFlag::CleanFileName::kRootDir = "foo";
}

?!?

I would think not, but that'd be the only way to set it. Possibly this variable was a real global variable at some point, but then made local static variable for some reason to "disable" this functionality.... I have no idea as I was not involved with the project when these changes/decisions were made.

@dreamer-dead
Copy link
Contributor

dreamer-dead commented Aug 3, 2016

Is it possible to do something like this:

Nope, it isn't possible.

If we need a way to set kRootDir to a user-defined value, we should provide a non const storage, for example in a global variable. There are some global variables, e.g.

static string argv0("UNKNOWN");  // just the program name
static string cmdline;           // the entire command-line
static string program_usage;
static vector<string> argvs;
static uint32 argv_sum = 0;

Maybe we should create another one for RootDir.

@schuhschuh
Copy link
Member Author

Yes, I guess a sensible thing to do would be to add functions in the style of the SetVersionString, and VersionString getter similar to this code.

static string kRootDir = "";

void SetRootDir(const string &path)
{
  kRootDir = path;
}

const char *RootDir()
{
  return kRootDir.c_str();
}

The reason these might not be present at the moment could be that unless it is clear how it should be used and how useful it is, there shouldn't be an addition to the public API unless we are clear about this new feature.

A question would be how to accommodate different root directories for flags defined in different shared libraries which may not be built by the same person. The kRootDir should then be a variable defined by each shared library during build time of the respective library. For the gflags library, this would thus need to be an attribute on a per flag (or flag group) basis. Not a functionality that is currently available.

But I guess if the creator of a shared library would want the file paths to be stripped off a certain build directory prefix, there could (in the future) be a way to modify directly the __FILE__ argument to FlagRegisterer instead of kRootDir via a preprocessor #define. And if that were possible, kRootDir might not be needed anyway.

@dreamer-dead
Copy link
Contributor

Should this be closed, since kRootDir was removed?

@schuhschuh
Copy link
Member Author

Fine by me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants