I'm writing a command-line utility in Go that (as part of its operation) needs to get a password from the user. There's a great gopass module for Unix that does this, and I know how to write one for the Windows console. The problem is that the Windows module obviously won't build on *nix, and the *nix version won't build on Windows. Since Go lacks any preprocessor support (as far as I can tell), I have absolutely no idea what the right way to approach this is. I know it's possible, since Go itself must do this for its own libraries, but the tooling I'm used to (conditional imports/preprocessors/etc.) seems to be missing.
Go has build constraints, which can either be specified as comments in a .go file, or as part of the file name.
One set of constraints is for target operating system, so you can have one file for Windows, one for e.g. Linux and implement the same function in two different ways in the two.
More information on build constraints are at http://golang.org/pkg/go/build/#hdr-Build_Constraints
Related
I'm writing my first KDE plasmoid using QML. The hello world example uses a metadata.desktop file, while this KDE Plasmoid tutorial talks about a metadata.json instead and says that the metadata.desktop is 'discouraged' now and a desktop file should be converted to json using desktoptojson.
However, when I browse the globally installed plasmoids under /usr/share/plasma/plasmoids/ they all have both the metadata.desktop and metadata.json.
First question: So, what is really recommended? Just the metadata.json? Or both?
And, I wasn't able to find the desktoptojson tool. I'm using Linux Mint and the ./kdesrc-build --initial-setup for debian based systems says that it's "This is woefully incomplete and not very useful" ... I read that "most users of this [i.e. desktoptojson] utility will use the CMake macro kservice_desktop_to_json as part of the process of building a plugin.". However, I haven't found the documentation yet how to use this.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
Thanks!
First question: So, what is really recommended? Just the metadata.json? Or both?
In the current source code, most stock KDE applets such as the task manager use metadata.json's and have dropped the metadata.desktop's. It may be that the desktop files you have locally are left over from old versions, the new format was installed but the old one was never deleted.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
The man page on Arch you linked to has all the information. The tool is part of the package kservice. Find the equivalent in the repository for your distribution. Then, to use it
as part of a CMake macro:
add_library(myplugin MODULE ${myplugin_SRCS})
kservice_desktop_to_json(myplugin myplugin.desktop)
directly on the command-line:
desktoptojson -i myplugin.desktop -o myplugin.json
I've searched far an wide for this specific problem, but I only find separate solutions for each problem individually. I basically want to know what the name of the environment variable should be. My assumption is that the name of the variable should be the name of the component and that it should be User variable and not System variable, for example:
name -> "mydll.dll"
path -> "c:\myCustomPath\mydll.dll"
The reason why I want to do this is because of two reasons. First, I often run my custom made tools either directly from the source code in a VM (which is sort of a pain), or I compile it and run it in W10. However, I just cannot do that with more complex apps that have dependencies because then I would have to register tons of DLLs onto the system root, and I know that I would lose track of it easily. The second reason is because I read this reply the guy says it's not recommended to use the system root for private libraries and he also suggests using an environment variable which sounded like a good solution to my problem.
The reason why I have not tested this myself through trial and error is because I'm afraid of leaving my only computer unusable if I put something wrong in the variable. Also all the libraries and exe files that I'm using are written and compiled in VB6, so I have no easy way around it since I already tried merging the multiple projects into one on a rather small project. I ended up rewriting almost the whole thing because VB6 doesn't like public types enums, etc in private Object Classes.
Finally, I am not sure if my question should be here since it doesn't involve programming, but I just felt it would be better understood here.
If I understand your question correctly, you are asking where you can place COM DLLs so that you can register them on your computer.
The answer is - fundamentally - that it does not matter where they are located because registration has a "global" effect. (Simplifying a little).
Now of course there are standards or conventions for where system-wide registered DLLs should go - e.g., Windows\SysWOW64 folder. But the point is that if you register the wrong thing, or leave out dependencies, or remove a registered DLL without unregistering it - etc. etc. - you will cause problems.
I am not aware of any environment variable that has anything to do with this basic function of COM DLLs. (I may be ignorant of something).
If you are actually using an application manifest (as maybe implied in the question) then you don't need to and should not register any DLL which is manifested.
First of all let me clear up some confusion arising from my potential misuse of vocabulary in the question:
By 'executable' I mean a single executable file that is build from sources containing one main function (my background is in C++) and potentially lots of classes and the like. This 'large software system' is a collection of such executables that communicate with each other and work together to achieve some goal.
I'm used to writing simple programs that have a clear entry point and exit conditions. What would be this entry point in such a software system? Which executable starts first and how do I know which one it is? There is no one global main function after all, is it? When are all other executables launched and who calls them? What other files compose such system? How are they bundled together? How is the system loaded on the target machine?
Question is way too vague, but I'll try and take a stab at it.
Which executable executes first - this would depend on requirements and the developer. If it's a sequential flow, there would definitely be an order of executing executables. For parallel processing, the return codes of each executable would be examined to determine their result.
Who calls other executables. This can be done by calling your initial executable from a shell script, and based on it's return code, deciding the next course of action. Instead of shell script, you can also opt for job schedulers like Tivoli or Cron jobs i believe.
What other files compose the system.
Well that would depend on the system being built. This is really extremely vague to even attempt to answer.
How are they bundled.
That would depend on the target system. Java apps could be .jar, in windows you can have .exe
How is the system loaded.
Again way too vague to answer
I'm using MSI to create a setup, it's all fine but I have a question that I got this:
Why do we get .dll and .DLL file? And what is the difference between them.
Thanks
There's no difference between them, just that the creator of the name and extension chose to name them that way. The Operating system considers them the same types of files. Same thing happens with .EXE and .exe, .AVI, .... Some organizations may consider it a naming convention.
On a Windows filesystem, there is absolutely no difference as file names are case insensitive.
The only time you will notice a problem is when accessing the filesystem through a file sharing protocol that is case sensitive.
That screenshot is Visual Studio Deployment Projects view and it appears it isn't smart enough to realize those are the same DLL's. I'd build the MSI and look at it in ORCA and see if it actually tried to package it twice and create a component rule violation in the process. It wouldn't surprise me at all but this isn't one of well known issues that I can recall at the moment.
In addition to Windows being case aware but case insensitive, fill extensions don't really matter that much either. A Windows dynamically loaded library (PE format) can be any extension as the LoadLibrary() function doesn't really care. Common extensions are .DLL, .SYS, .OCX and .DRV.
I have installed both the GNAT Programming Studio (GPS) and GtkAda. They both seem to work fine, but when I try to build the Simple Window project under New Project from Template, I get a bunch of errors saying "file gtk.ads not found." This seems to be a directory/dependency sort of problem - GPS doesn't know where to look for GtkAda. I'm running Windows 7, and have GPS installed at C:\GNAT\2011, and GtkAda installed at C:\GtkAda. I tried adding GtkAda to my PATH; at the moment my PATH user variable includes C:\GNAT\2011\bin, and my Path System variable includes C:\GtkAda\bin. Any advice on resolving this problem is greatly appreciated!
There are two things here.
First, "project" is key. Whenever you're building something that depends
on a library like GtkAda, it's much much easier if (a) you use GNAT
Project to manage it, and (b) you use the GPR(s) provided by the library
- always assuming it does, of course.
In the case of GtkAda, that means that your GPR needs to "with" GtkAda;
with "gtkada";
project Tinkering is
...
Second, gnatmake or gprbuild needs to be able to find gtkada.gpr.
The easiest way is to install GtkAda in such a way that gtkada.gpr is in
the default place that gnatmake/gprbuild expect to find GPR files. This
is $prefix/lib/gnat. GtkAda obeys this convention, so you could install
GtkAda under the same root as your compiler. I don't know why that's not recommended anyway.
If you don't want to do that, you can add the correct location to the
environment variable ADA_PROJECT_PATH, for example in your case set it
to C:\GtkAda\lib\gnat.
There is a lot of good stuff in the GtkAda README at libre.adacore.com, and in
the GtkAda User's Guide which I see from the README is also included with the
installed package at (in your case) C:\GtkAda\doc\GtkAda\gtkada_ug.