the system options shows other than english on the SAS product, due to which some of the properties and also the help manual is not in english, how is it possible to change it? or do I have to install the SAS again?
As long as you installed the correct language(s), it's possible to run SAS in different languages. However, if you only installed one language, it will be sufficiently complicated that I would recommend an update installation (which is not a full reinstall).
This SAS technical support note covers this in some detail; it also recommends an update installation if you didn't install the language originally.
What you can do is look at the SASFoundation folder in your install, usually one more folder deep (the version), and then look at the nls folder. nls refers to language support, and it should have one folder for each language installed, including Unicode support and DBCS support. \nls\en will exist if you installed English.
If that's the case, you can edit your sasv9.cfg to point to the config file you want to use - ie, the \nls\en config file. It probably points to whatever you currently are running.
You also can on the fly run one or the other simply by including in the shortcut or launch program the -config option pointing to the config file you want.
Related
I'm creating a Qt gui application using a library which searches the PATH environment variable for certain executables, namely compilers, make and cmake.
The problem is that std::getenv("PATH") returns something different in the gui and certain executables are missed. I've tried to use the QProcessEnvironment class to the set the PATH, however, the same problem arises. I can set it to specific paths in my machine but it would be great if it could get the PATH of any machine the application is deployed to.
Strangely if I start the gui using the command-line, everything works out fine! Although I find it unreasonable to ask users to open the gui using the command line.
Any help would be greatly appreciated.
This problem has nothing to do with Qt. You've set the PATH using shell initialization scripts and such, in your own user folder. It'd be a terribly bad idea for the graphical shell to use that path, as a mistake in your shell profile would potentially make the entire desktop non-functional. Of course it works from the command line, since your shell profiles take effect then.
You could, as a user configuration option, extract the shell PATH by running the equivalent of user's $SHELL -c 'echo $PATH', and processing the result.
Otherwise, you'll have to defer to what's customary on the platform, and consult package managers if needed. Different package systems tend to install these tools in different directories, but there is just a few common ones. I presume it'd be enough to cover Ubuntu, RedHat, macports and homebrew, and make sure that you check in "pure" FHS (Filesystem Hierarchy Standard) locations as well.
I have developed an application that I plan to deploy on Windows, Mac, and Linux. The program requires access to some files (scripts and the like) at run-time.
The installation process should install the files to a location that my application can later determine without user-intervention (or perhaps just a prompt allowing the user to change the location, if desired).
What is the best way to achieve this? I can't seem to find any way to:
1. Use a "standardized path" variable in the project file's INSTALLS statement. (e.g., my application could use QStandardPaths to initialize the location, but I can't figure out how to access this path from the INSTALLS statement)
2. Save the path to my project's QSettings (.plist, registry, whatever) for later retrieval
That leaves me with creating a custom project file and INSTALLS command for each environment, and then I still can't install to the user's directory because I don't know the user's name when I deploy the make command. It seems as if there must be a better way, but I can't seem to find any documentation for this. Am I just using the wrong keywords in my searches? Thanks in advance!
What standard directory? What type of getting that standard directory?
For instance, you can put such thing in your windows branch of .pro file:
win32 {
APPDATA_DIR = $$system(echo %APPDATA%) # should be %LOCALAPPDATA% as requested
message($$APPDATA_DIR)
}
Just unsure of what exact kind of standartized path you are talking about. QStandardPaths knows many. It makes sense to be more concrete to find the correspondence with concrete OS.
Also somewhat relative reply on mine, on how to check the correspondence with certain variable, etc: Qt .pro file - how to add conditioning on OSX version?
Maybe this class will help you
QStandardPaths documentation
But your problem is still little bit unclear for me.
I have a package I want to install. I would like the files to end up in a different directory than the installation wizard choses for them.
For example, my Sitecore copy is running at C:\SiteCore\website
The module added files to C:\SiteCore\website\Console
I would like the files to ultimately live at C:\SiteCore\website\sitecore_modules\Console
I am using Sitecore 6.5 rev 111230, but we are planning to upgrade very soon. I would like for my installed packages to migrate seamlessly once we have upgraded. For reference, the package I want to install at the moment is the Sitecore Powershell Extensions. Although, I would prefer to apply a similar method to any future packages that I install.
Is there a secret switch in the package installation process to allow me to do this? Can I do it from the package installation wizard? Is there another way to install packages?
I'm assuming I can't just change the package path and expect everything to keep working. Do I have to update a configuration somewhere (a file or inside the Sitecore CMS GUI) to make the package recognize the new file locations?
The module creator defines where files exist. If you move them you run the risk of something not working. The best idea is to ask the creator on the Marketplace page of the module.
There is no turn-key way to change this.
I guess you cand take the code from MarketPlace and you can modify it.
I don't know how exactly is the licenses with MarketPlace modules, but I think people can modify others code.
Please check on code and also on items, maybe on some fields are values for folder path.
I discovered a way to accomplish this, but it can be quite involved or even impossible, depending on the complexity and size of the package.
First of all, I did take the question to the module creator and had a very helpful and informative conversation with the creator. So thanks for that suggestion - they may even move the install location in a future release, based on my request.
The workaround is to first install the package on a system as normal. Then you figure out everything that comes with the package. For files, this is easy if your Sitecore root is under source control. For items, this is really complicated. You can search for the installed items by owner, if you had the foresight to create & use a unique user for the package installation. Or you can check the untyped files in the package that are essentially xml based item manifests.
Once you have a detailed list, you make the desired modifications to the locations. Then you recreate the package yourself using the Sitecore package designer.
This works for simple packages - I did it to one small package that I hope to get up on the Sitecore marketplace as shared source soon. And by small, I mean it was 2 files and 3 items. The package that prompted me to ask this question would not cooperate with this workaround. The included .dll had some assumptions about the file structure hard-coded into it.
The workaround I took for the more complex package was really quite basic: I just created a new source-code external to the required path. That let me wrap everything up neatly without getting medieval on the package files.
Thanks for both your answers, a very fine +1 to you.
I have found a problem with the test environment in a c++ problem.
We have a machine which downloads the code from the version control system and, build it and execute the unit test, nothing new.
The problem arise when we add a new dependency in our project. We are developing a lot of features at the same time and it is something relatively common. We this happens we have to advise testers and give them an easy way to reproduce the compilation environment ...
And I was thinking if there is any other easy way to go through this ... don't know, some tool like virtualenv or buildout for python ..
I have been searching at google, but with no luck.
Any help will be appreciated.
You can always add all of the dependencies to the revision control system and provide automated scripts that will install the required subsystems. Where I work, if you just download the current version from the repository, you can build in one step an ISO image that can be installed by testers in any computer they want. The image contains everything from the OS up to the application.
Depending on your particular situation, you might want to start with smaller steps, like adding the dependencies to the repository and having the testers check there whether any new file appears or changes version.
No ready tool, AFAIK, except maybe for CMake which can control things like that for you.
For C++, it's fairly easy to manage "by hand" since you can set LIB, LIBPATH and PATH environment variables to carefully selected directories. No site.py, eggs, .pth files and the like as with Python.
We do this at our shop, setting up our build/development environment closely and have everything in revision control (mostly scripts that download huge zips of prebuilt libs and unpack them to the right places).
Small libs are copied to common dirs, larger get their own entry in the env-vars.
This works equally well for Python and Java. Haven't tried other languages...yet. :)
I'm trying to design an SConstruct file for an embedded system project. The compiler on my machine is at "C:\Program Files\IAR Systems\Embedded Workbench 5.4\arm\bin" I would like the build system to try to locate the toolchain even if there is another verison of Embedded Workbench installed, or if the user has chosen to install it elsewhere.
I'd also be interested in strategies used in makefiles or ant files since they are probably useful here as well.
What are some strategies for doing this? Do I have options other than searching the Windows registry or looking for "C:\Program Files\IAR Systems\Embedded Workbench *\arm\bin"?
The simplest solution is to use an environment variable. You still have to set that up manually for each build host, but the build system need only refer to the environment variable, so can be common for all build hosts.
For example in your case you might have:
EWBARM_V0504="C:\Program Files\IAR Systems\Embedded Workbench 5.4\arm\bin"
And similar for other versions installed, and then in your build system you would use %EWBARM_V0504% in place of the path. The worse that will happen is if the variable does not exist the build will fail, which is preferable to using the wrong compiler, and easily fixed.
Since different versions of toolchains may have different bugs and/or features, silently falling back onto different sets of tools is probably a bad idea. When I've supported multiple tools versions on a single project, I usually have the version number assigned via a makefile or the environment. Then you can pass -D TOOLS_VERSION=$(TOOLS_VERSION) to your compiler and use that value to key bugfixes and workarounds you need for particular versions of the tools. This system makes it clear which tools you want to support, while still making it easy for other developers to switch tool versions by making a single edit.
The nice thing about SCons is you have all of python at your disposal. So you can use win32.winreg to look in the registry, or glob around in sets of paths, whatever works for you. And of course you can have a command-line option or an options file to override the autodetection. Then once you've found your tool of choice, you have basically two ways to make SCons use it: either prepend the tool's dir to env['ENV']['PATH'] (you can use env.PrependEnvPath for that), or just use the tool's full path as the value of your $CC (and set $LINK, $SHLINK etc. appropriately too).
I usually make a TOOL_MYCOMPILER function that takes an env and sets it all up for use with the compiler and its toolchain (cpp, linker, whatever). It keeps things cleaner in your SConstruct/SConscript.