I work on software that requires access to DLLs, usually wants environment variables set a certain way, and can take command line parameters. I'm generally opposed to setting/modifying system-wide environment variables for the purpose of launching these apps, since I might want to use different dependencies (different dlls), etc. and I don't want to accidentally get the wrong DLL loaded.
Up until now, I've been generating the visual studio .vcproj.user files and matching batch files from cmake ( see here for my script ) that extends the path to include the path to my dlls, sets any other environment variables as needed, and launches the application, forwarding all the command line arguments. (I do the same on Linux, but it's simpler because of RPATH). When we want to launch with a command line argument that wasn't just a file we could drop on the batch file, what we did is copy the batch file and edit the command to add our argument. (It's all GUI applications, but config files/flags can be passed on the command line)
This has become quite a hassle for me and my colleagues, and we end up with a ton of batch files, named similarly and difficult to maintain. It's not really a great interface for starting but there's a lot of apps we either use or develop that are like this, so it's a common task.
My question is this: I'd like a nicer way to configure dynamic library search paths, process-local environment variables, working directory, executable, and arguments for starting a program than hand-editing a batch file every time. I've done some digging to try to find one, but haven't been successful - "launcher" tends to bring me to "search-as-you-type" tools for frequently-used apps, and "command line argument" tends to find recommendations to use batch files. (It's not a windows-specific issue, either, but the dynamic library path stuff is less problematic during the code/compile/run cycle)
I've made a quick mockup of what I'm envisioning: it seems like the kind of thing that has to exist somewhere. Do you know of a tool similar to this (preferably cross-platform, and open source is even better)? It doesn't need all bells and whistles I put in the mockup, but that's what I'd build if I had time to build it myself. Thanks!
Related
I am developing an OS for embedded devices that runs bytecode. Basically, a micro JVM.
In the process of doing so, I am able to compile and run Java applications to bytecode(ish) and flash that on, for instance, an Atmega1284P.
Now I've added support for C applications: I compile and process it using several tools and with some manual editing I eventually get bytecode that runs on my OS.
The process is very cumbersome and heavy and I would like to automate it.
Currently, I am using makefiles for automatic compilation and flashing of the Java applications & OS to devices.
All steps, roughly, for a C application are as follows and consist of consecutive manual steps:
(1) Use Docker to run a Linux container with lljvm that compiles a .c file to a .class file (see also https://github.com/davidar/lljvm/tree/master)
(2) convert this c.class file to a jasmin file (https://github.com/davidar/jasmin) using the ClassFileAnalyzer tool (http://classfileanalyzer.javaseiten.de/)
(3) manually edit this jasmin file in a text editor by replacing/adjusting some strings
(4) convert the modified jasmin file to a .class file again using jasmin
(5) put this .class file in a folder where the rest of my makefiles (the ones that already make and deploy the OS and class files from Java apps) can take over.
Current options seem to be just keep using makefiles but this is a bit unwieldly (I already have 5 different makefiles and this would further extend that chain). I've also read a bit about scons. In essence, I'm wondering which are some recommended tools or a good approach for complicated builds.
Hopefully this may help a bit, but the question as such could probably be a subject for a heated discussion without much helpful results.
As pointed out in the comments by others, you really need to automate the steps starting with your .c file to the point you can integrated it with the rest of your system.
There is generally nothing wrong with make and you would not win too much by switching to SCons. You'd get more ways to express what you want to do. Among other things meaning that if you wanted to write that automation directly inside the build system and its rules, you could also use Python and not only shell (should that be of a concern though, you could just as well call that Python code from make). But the essence of target, prerequisite, recipe is still there. And with that need for writing necessary automation for those .c to integration steps.
If you really wanted to look into alternative options. bazel might be of interest to you. The downside being the initial effort to write the necessary rules to fit your needs could be costly. And depending on size of your project, might just be too much. On the other hand once done with that, it'd be very easy to use (apply those rules on growing code base) and you could also ditch the container and rely on its more lightweight sand-boxing and external rules to get the tools and bits you need for your build... all with a single system for build description.
I'm working on a plugin for a very niche CAD application that our company uses. The development environment is entirely based on Emacs and everything should be done through it.
In this case, code should be edited, navigated, compiled and debugged using Emacs. There is no separation from Emacs and the actual language compiler (from what we know so far - there is no compiler.exe).
Since my team is not a fan of Emacs we are trying to get rid of this dependency so we can use whatever editor we want an compile/interact with the application without Emacs, but looks like this is very hard because everything is built inside it, even go-to definition, find all references all and sorts of commands.
These are all defined in hundreds of .el files (LISP) that are called using custom commands from Emacs.
However, when calling "Run this file" for example, said file is ran inside the application and correctly executed so my question is: what mechanisms could be used used for this to happen? I don't expect precise answers as I can't share the name of the actual CAD application or anything else, but it would be really helpful to understand what options are possible so I can investigate them.
In summary, whenever I "Run this file" the actual application is started by Emacs by calling the command line and the actual file gets executed inside the application. Looks like the contents of the Emacs buffer are passed to the application somehow. This "how" is what I'm trying to find.
Thanks for any help.
C:\Users\redacted\Documents\redacted>gfortran hibrac.f -o hibrac.exe
'gfortran' is not recognized as an internal or external command,
operable program or batch file.
https://gcc.gnu.org/wiki/GFortranBinariesWindows seems similar to my problem: gfortran.exe is in C:\Windows\MinGW\bin -- except the solution appears not to apply to Windows 8.1 Pro:
Right click on My Computer, Properties, Advanced Tab, Environment Variables.
Instead I tried: Right click on 'This PC' within File Explorer, Properties, Advanced system settings, Advanced Tab -- and I cannot find an equivalent-looking section that allows me to proceed with the advised solution.
As background information:
I had installed MinGW Installation Manager which installed mingw32-gcc-fortran (together with mingw32-base, -gcc-g++, and -gcc-objc) in the recommended C:\Windows\MinGW folder, without any apparent error message.
Isn't it acceptable -- standard practice -- to have one's code in a folder separate from this MinGW folder? i.e. a subdirectory of my Users\account rather than a subdirectory of MinGW. This isn't the problem, is it? What do I need to do to get it to recognize the gfortran.exe, or call it correctly?
Please tell me what to do to get it working. If it's relevant, I have a Japanese computer with an English language pack installed (it seems to have some gaps, such as some text in the Settings charm or startup/shutdown text being in Japanese).
This looks very much like you have neglected to add C:\MinGW\bin to the effective PATH for the command window, in which you are attempting to run the gfortran command.
Your question isn't entirely specific on this point, (i.e. you could improve the question), but you hint that you were unable to add the appropriate PATH entry to the global environment variables, because you couldn't find the appropriate control panel applet? I know that this is often recommended as part of a MinGW setup, but the installer will not do it for you, because I, as the maintainer of mingw-get, don't consider that to be best practice; much better, IMO, to add it for each specific command window in which you need it to take effect, by running (once, at the start of each command prompt session) the command:
path %PATH%;C:\MinGW\bin
If you prefer, you may create a batch file to do this for you, along with any other initializations you wish to perform, (or better still, use MSYS as the working shell environment, in which case the PATH initialization is taken care of by the shell's own initialization scripts).
EDIT: This is due to stupidity. It is a multiple monitor issue. It's just that from cmd.exe we always opened in the primary monitor, whilst from explorer, we always opened in the secondary. Thanks all for the help!
We hit a weird bug recently. We have a Qt + osg app that behaves differently if we run it from explorer than if we run it from a command line. Running from explorer is unusable, while running from command line (or by running from the explorer a simple batch file that calls the .exe) works as expected.
We suspect environment variables, because that's all we can think of. But the fact that it runs fine with a one line batch file seems to refute this. I'm not familiar enough with windows to know of any subtle differences in how it loads executables, nor where to look to find out.
Are there any other differences that could explain this? Does windows load different sets of user environment variables in each case? OS is Windows XP Service Pack 3.
The behavior experienced when running from explorer (double click program.exe) is consistent with a driver issue or improper OSG scene setup: image artifacts, flashing, and weird colors.
The behavior experienced when running the same executable from cmd.exe (or by double clicking a .bat file next to the .exe containing only a line to run the .exe) is the correct, expected behavior: the scene is correct, no flashing, etc.
To rule out potential library load path issues, try using dot-local DLL redirection.
Towards that end, create an (empty) file in the same directory as your executable and give it the same name as your binary, except with .local appended. I.e., if your binary is named yourbinary.exe, name that file yourbinary.exe.local. That will force the PE loader to first look in that directory to resolve LoadLibrary calls (and that includes DLLs loaded indirectly via system DLLs or via COM, no matter how many indirection levels are involved.) Place as many supporting DLLs (including Qt DLLs) in that directory. If you're using Qt plugins, also place the plugins directory there (or use a custom trolltech.conf.)
More details on dot-local redirection here, for example.
This thread looks like it might have the answer to your question:
http://forum.soft32.com/windows/Start-Run-Command-Prompt-ftopict353085.html
In short, I think it might be looking for your executable in different places depending on which method you attempt to use to run it. Perhaps you have 2 different versions hiding somewhere that explorer uses instead of the one you want?
You have not given enough details so I will give you a general answer. In order to use QT and its tools you need 2 environment variables. *QTDIR, and PATH * Make sure you have these variables set instructions are below. I have taken them from this site. See also this link for deployment on windows.
Setup the QTDIR environmental
variable.
1) Create a new System variable
called: QTDIR
a. Right click on My Computer -> Properties -> Advanced Tab ->
Environment Variables button
b. Find System variables -> New -> Type in "QTDIR" 2) Set the value to: C:\your\Qt\directory (NOTICE: No
trailing '\' character!!!)
Now, add the QTDIR on to your PATH
variable.
1) Edit your PATH variable, add onto
the end of it a ';' if one isn't
already on the end. 2) Now add on:
%QTDIR%\bin;
Example:
Before
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;
After,
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%QTDIR%\bin;
That will make sure that our Qt
application(s) will be able to find
the Qt DLL files when you go to run
it.
I hope this helps.
Perhaps there is a difference caused by the way Explorer launches an executable vs directly running it from the console. I think that Explorer uses ShellExecute or ShellExecuteEx and I doubt that executing an application from a console or batch file does the same.
I would create a test app that tries some of the ShellExecute variants and use different parameters to see if the Explorer behavior can be reproduced in order to try to diagnose what parameters passed to ShellExecute might be causing the problem.
There is an interesting community note on the ShellExecuteEx page that may or may not be applicable:
ShellExecuteEx ignores the current input desktop. It always uses winsta0\default. Instead use ShellExecute or CreateProcess.
I would also investigate whether or not AppCompatFlags affect console executed applications (or see if any AppCompatFlags have been set for your application).
I've developed a GUI for some build scripts, and am now in the process of deploying it. As the script will be deployed to a number of different machines at various points, I need to use the standard format of directories that the team use.
The GUI consists of a ".fig" file that contains the visual definition of the UI, and a m-script that defines the functionality. I need to locate these two in "fig/" and "m/" folders respectively, but I can't figure out how to. I first searched for an include statement of some kind in the m-script, as when I Run it on its own, the error message in the command window states that the ".fig" file can't be found, but there doesn't seem to be a reference to the ".fig" file anywhere, I assume that it's inferred as both files have the same name but a different extension.
I fear that Matlab's GUI system requires that both ".m" and ".fig" files are in the same location, but this will be an inelegant solution that I'd rather not go for if I can avoid it.
The next thing I'm going to try is to call a script that copies the fig file from the other directory to the same location as the m-script, when it is executed, then deletes that copy once the script exits, which again seems a clunky solution, but will allow me to adhere to the team's organisation conventions.
Does anyone else know of an undocumented means of specifying the relative location of a GUI ".fig" file?
You can export the GUIDE-generated GUI as a single .m file. Check out this blog post: GUIDE GUIs in All One File.
I'm not sure if this is a new feature, or one of those things that has always been there...