I am aware of using GST_PLUGIN_PATH to list the search paths used by the plugin registry in resolving plugins. In my specific case, I want to exclude a particular element by name that happens to reside in a plugin containing other elements that I don't want to exclude. I.e., I don't want to exclude an entire plugin, just some of it's provided elements.
(Luckily, the provider of this plugin makes their source available, and I can rebuild it with some modifications to remove certain elements, but I'd rather not rebuild the plugin.)
An environment variable is preferable, but any configuration-based method could potentially help. Specifically, something that is honored by the gst-launch-1.0 and gst-inspect-1.0 cli tools.
Related
There's a file, just a single file, there's no shards or anything else.
/alex/projects/inspector/inspector.cr
I want to require it in another file in another folder
/alex/projects/my-project/play.cr
This won't work
require "/alex/projects/inspector/inspector"
require "/alex/projects/inspector/inspector.cr"
This also not working
CRYSTAL_PATH=$CRYSTAL_ROOT/src:lib:/alex/projects/inspector
require "inspector"
require "inspector.cr"
require "./inspector"
require "./inspector.cr"
P.S.
I would like to avoid using shards etc. as I have no plans to share that file or publish it. It's just a file that used by couple of other files in different locations.
I solved it by creating symlink
ln -s /alex/projects/inspector/inspector.cr /alex/projects/my-project/inspector.cr
require "./inspector"
Currently, require is only relative (as you learned from your forum post). However, you were on the right track with CRYSTAL_PATH.
CRYSTAL_PATH is an environment variable used by the Crystal compiler which tells it where to look for dependencies. So instead of using it in code, as it appears you did, you should use it when building the executable:
CRYSTAL_PATH=$CRYSTAL_ROOT/src:lib:/alex/projects/inspector crystal build /alex/projects/my-project/play.cr
Note that CRYSTAL_ROOT must be defined for that exact command to work. If you need to find the current CRYSTAL_PATH in order to append to it, you can use crystal env.
I have following scenario:
The main software I wrote uses a database created by a simulator. This database is around 10 GB big at the moment, so I want to keep only one copy of that data per system.
Assuming I have following projects:
Main Software using the data, located at /SimData
DLL using the data for debugging, searching for data at /SimData
Debugging tool to parse the image database, searching for the data at /SimData
Since I do not want to have all those programs have their own copy of SimData (not only to decrease place used, but also to ensure that all Simulation data used is always up to date for all programs).
I created for the DLL and Debugging Utility a link named SimData to MainSoftware/SimData, but when opening a file with "SimData\MyFile.data" it cannot find it, only the MainSoftware with the ACTUAL SimData folder can find it.
How can I use the MainSoftware/SimData folder without setting absolute paths?
This is on Windows 7 x64
I agree with Peter about adding the DB location as a configurable parameter. A common place to store that is in the registry.
however, If you want to create links that will be recognized by your software, try hardlinks. . fsutil should do the trick as described here.
You need a way to configure the database location. You could use an INI or other configuration file, or a registry setting, or a command-line input, or an environment variable. Or You could write your program to search a directory hierarchy... for example, if the various modules are usually siblings of each other in your directory tree, you could search for SimData/MyFile.data, ../SimData/MyFile.data, ../../MainSoftware/SimData/Myfile.data, and use the first one found.
Which answer is the "right one" depends on your situation.
I have several (15 or so) builds which all reference the same string of text in their respective build process templates. Every 90 days that text expires and needs to be updated in each of the templates. Is there a way to create a central variable or argument
One solution would be to create an environment variable on your build machine. Then reference the variable in all of your builds. When you needed to update the value you would only have to set it in one place.
How to: Use Environment Variables in a Build
If you have more than one build machine then it could become too much of a maintenance issue.
Another solution would involve using MSBuild response files. You create an .rsp file that holds the property value and the value would be picked up and set from MSBuild via the command line.
You need to place it into somewhere where all your builds can access it, then customize your build process template to read from there (build definitions - as you know - do not have a mechanism to share data between defs).
Some examples would be a file checked into TFS, a file in a known location (file share), web page, web service, etc.
You could even make a custom activity that knew how to read it and output the result as an OutArgument (e.g. Custom activity that read the string from a hardcoded URL).
I have a simple build definition which I want to use to build just one project, and every time I choose to run this build, I want to get latest from the branch/directories that pertain only to the project in question. How do I do that? The call to "Get Workspace" gets everything from source control, and I do not want to (or need to, for that matter) get latest from everything for various reasons.
I hope I am not asking for much.
Thanks in advance.
Check the workspace mapping in the build definition. The build only gets the items that you have specified over there. If you want to exclude some folders within the path that you are mapping, you can choose to cloak some folders.
You can adjust your ItemsToBuild in Process Tab in Required section
I have a fairly large C++ application (on Windows, no other platforms planned), which currently stores all settings (even some kind of addresses) in the Windows registry.
Sometimes this is inconvenient, because the users have difficulties changing entries in the registry. I would like to have settings versioned, so settings always match the current code. At the moment we version reg-files, but you are never sure, if all reg-files have been added on the target machines. With C# you can define default values in app.config, but don't overwrite existing settings. I don't know, if such a mechanism or library exists for C++.
I would like to have the following "features":
Settings can be versioned
Simple update on target machines (can be done by user)
Ensure that on update only new settings are added and no existing settings are overwritten with default values
Simple change of settings for user
Same workflow under Win XP and Win 7
As far as I see it, there are 3 possibilities to store settings on Windows:
Registry
Ini file
XML file
Only one application of our suite uses Qt at the moment, but Boost would be available.
For addresses, we will put them in some kind of XML address book, but for the other settings we are not sure, what's the best practise.
As comments mention, tree-based key/value structures are a common solution and libraries are easy to find.
Boost's property_tree is an excellent choice, as it is well-tested and can easily be exported as XML or JSON
Regarding your requirements:
Settings can be versioned
Yes! Make "version" a top-level key. Make it easily comparable with other versions.
You can also categorize your settings into various tree nodes and give each node a version.
Simple update on target machines (can be done by user)
Have your application do that when it runs. See below.
Ensure that on update only new settings are added and no existing settings are overwritten with default values
Simple change of settings for user
Same workflow under Win XP and Win 7
As settings change from one version to another, usually these changes fall into three categories. New properties are needed, old settings are abandoned, and some settings change their expected format. E.g. "32 Fahrenheit" becomes "0 Celsius"
When your application initializes:
Load the existing configuration file, regardless of its version.
If the version does not match what's current for the application:
Create a new blank property tree for the new configuration
For each node in the tree, have a set of expected property names, and a function pointer or similar to get this setting if it's absent in the old file's tree. If a setting changes its format, give it a new name.
Search for each setting in the old tree, copying it if it's found, and using the result of the supplied function if it's not.
Save your new settings file.
Your "missing setting" functions can:
Return a constant default value.
Query the tree for a different setting and convert it (with a default value if the old setting isn't found either)
Ask the user