I'm trying to write some complex Starlark rules that link and build multiple dynamic libraries on Linux using the (relatively) new cc_common APIs.
There seems to be 2 different ways you can create compile/link actions using this API:
Using the compile()/link() methods, which are relatively "high-level", and
Using the create_compile_variables()/create_link_variables() along with get_memory_inefficient_command_line() and then calling actions.run() directly with the generated command line.
In particualr, I'm trying to get #2 to work. My question is, how can I create the param_file to pass into create_link_variables? There doesn't seem to be any Starlark API for this.
https://docs.bazel.build/versions/1.1.0/skylark/lib/cc_common.html#create_link_variables
agoessling I have shared a couple of source files for you here
It should give you a pretty good idea of how this lower level cc_common API can be used end to end.
There are still known holes in this API, i.e. not everything possible with the built-in cc rules also possible through cc_common, but I would say 90% is available.
I am not associated with the Bazel team and the code is the result of my own digging and sniffing. No warranties, but it works for me. Let me know if you get stuck on something - I will try to help.
If you get an idea of how to do some of it better (prettier, more compatible with the built-in rules, more platform-independent, etc.) I am all ears. Good luck!
Related
I ask my question in such a specific way because I am afraid that a more generic form could lead to excessively theoretic discussions of how the things should be done best and in the most appropriate way (like a question about pre and post-process actions in SCons).
WPP incorporation actually requires execution of an additional command (commands) before compilation of a file and only even if the build process finds necessity to compile the file without any regard to WPP.
I would remark that this is easily achieved with few lines of definitions in a shared Visual Studio property page file making this work for multiple files in multiple projects, folders, etc. in an absolutely transparent for developers way.
Thus I am wondering whether this can be done in a similarly simple way with SCons? I do not have any deep knowledge of either SCons or MSBuild frameworks; I work with them for simple practical use so I would truly appreciate a practical and useful advise.
Here's what I'd suggest.
SCons builds command lines from Environment() variables.
For example the compile command line for building shared object for c++ is stored in SHCXXCOM (and the variable for what is displayed to user when the command is run defaults to SHCXXCOM, but can be changed by modifying SHCXXCOMSTR).
Back to the problem at hand.
Assuming you have a limited number of build steps you want to wrap, you can do something like.
env['SHCXXCOM'] = [ 'MPP PRE COMMAND LINE', env['SHCXXCOM'], 'MPP POST COMMAND LINE']
You'll have to figure out which variables you need to do this with, but take a look at the manpage to figure that out.
https://scons.org/doc/production/HTML/scons-man.html
p.s. I've not tried this, but in theory it should work. Let us know if not.
Recently，I need to realize a little function in MFC by C++ which is used to get a list of available serial ports. And then I saw this. I need to know what is SetupAPI1 and SetupAPI2? Where can I get the setup.dll when I wanna use this way to realize my function?. During searching the Internet I found there is a SetupAPI but it seems another one. Now, I am really confusing by these SetupAPI, SetupAPI1, and SetupAPI2. What are the differences? Where are they come from? And, how can I get them if I wanna to use these?
There is no such think as SetupAPI1 and SetupAPI2. There is a library named SetupAPI.
This answer you link to refers to a library named EnumSerialPort. From that page:
Internally the code provides 9 different ways (yes you read that right: Nine) of enumerating serial ports: Using CreateFile, QueryDosDevice, GetDefaultCommConfig, two ways using the Setup API, EnumPorts, WMI, Com Database & enumerating the values under the registry key HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM.
...
All of the configuration of the code is controlled by the following preprocessor values: CENUMERATESERIAL_USE_STL, _AFX, NO_ENUMSERIAL_USING_CREATEFILE, NO_ENUMSERIAL_USING_QUERYDOSDEVICE, NO_ENUMSERIAL_USING_GETDEFAULTCOMMCONFIG, NO_ENUMSERIAL_USING_SETUPAPI1, NO_ENUMSERIAL_USING_SETUPAPI2, NO_ENUMSERIAL_USING_ENUMPORTS, NO_ENUMSERIAL_USING_WMI, NO_ENUMSERIAL_USING_COMDB & NO_ENUMSERIAL_USING_REGISTRY.
This library presents two different methods that rely on SetupAPI, and simply numbers them one and two. You can see these details and more by following the links.
Is there any way with pure ColdFusion/cfscript to produce a QR code, without relying on external APIs or JavaScript?
No. ColdFusion cannot generate bar codes by itself. You need a separate tool or library. It is easy enough to install a java library, like ZXing. Then generate the images from CF. Alternately, you could do a <cfhttp> call to an external server that generates the bar code image for you, or basically do the same thing with javascript. You would not need to install anything for the latter two (2) options. But they still rely on an external resource.
Bottom line you need something more than just ColdFusion. What is the reason you cannot use either an external API or javascript? Because without either of those, you are probably out of luck.
Edit based on comments:
If the only restriction is the images must generated locally, then you can use ZXing as described in the link above -OR- any of the other components/libraries mentioned in the other responses, like Joe's suggestion which uses iText (though also based on ZXing).
Some other external APIs
http://cfbarbecue.riaforge.org/
http://zanstra.com/my/Barcode.html?barcode=3PTSP8827A231
If you really wanted to, you could look up (perhaps you need to buy?) the encoding standard for QR codes, which I believe is an ISO standard. Then you could write a program which would output a table with the appropriate number of rows and columns, each with either a black or a white background. I wouldn't recommend this form of "rolling your own" though; it's a lot of work to do essentially what's been done before.
Tim Cunningham wrote a library that is hosted on Github that utilizes iText that does just this very thing. https://github.com/boltz/QRToad
What does it take to build a Native Client app from scratch? I have looked into the documentation, and fiddled with several apps, however, I am now moving onto making my own app and I don't see anything related to creating the foundation of a native client app.
Depending on the version of the SDK you want to use, you have a couple of options.
Pepper 16 and 17: use init_project.py or use an example as a starting point
If you are using pepper_16 or pepper_17, you will find a Python script init_project.py in the project_templates in the SDK. It will setup up a complete set of files (.cc, .html, .nmf) with comments indicating where you need to add code. Run python init_project.py -h to see what options it accepts. Additional documentation can be found at https://developers.google.com/native-client/pepper17/devguide/tutorial.
Pepper 18 and newer: use an example as the starting point
If you are using pepper_18 or newer, init_project.py is no longer included. Instead you can copy a very small example from the examples directory (e.g., hello_world_glibc or hello_world_newlib for C or hello_world_interactive for C++) and use that as a starting point.
Writing completely from scratch
If you want to write your app completely from scratch, first ensure that the SDK is working by compiling and running a few of the examples. Then a good next step is to look at the classes pp::Module and pp:Instance, which your app will need to implement.
On the HTML side, write a simple page with the EMBED element for the Native Client module. Then add the JavaScript event handlers for loadstart, progress, error, abort, load, loadend, and message and have the handlers write the event data to, e.g., the JavaScript console, so that it's possible to tell what went wrong if the Native Client module didn't load. The load_progress example shows how to do this.
Next, create the manifest file (.nmf). From pepper_18 and onwards you can use the generate_nmf.py script found in the tools/ directory for this. If you want to write it from scratch, the examples provide examples both for using newlib and glibc (the two Standard C librares currently supported). See hello_world_newlib/ and hello_world_glibc/, respectively.
If you haven't used a gcc-family compiler before, it is also a good idea to look at the Makefile for some of the examples to see what compiler and linker flags to use. Compiling both for 32-bit and 64-bit right from the beginning is recommended.
Easiest way is to follow the quick start doc at https://developers.google.com/native-client/pepper18/quick-start, in particular steps 5-7 of the tutorial ( https://developers.google.com/native-client/pepper18/devguide/tutorial ) which seems to be what you are asking about.
I was looking for a solution to store program settings or options or configuration in C++. These could be settings that are exposed in a GUI and need to be saved between runs of my code.
In my search I came across boost.PropertyTree which seemed to be a good choice. I know boost is well respected code so I'm comfortable using it and so I started developing using this. Then I come across boost.program_options which seems to allow you to do the same thing but also looks more specialized for the specific use-case of program settings.
Now I'm wondering which is the most appropriate for the job? (or is there a 3rd option that is better than both)
EDIT:
fyi this is for a plugin so it will not use command line options (as in, it's not even possible).
UPDATE
I ended up sticking with boost.PropertyTree. I needed to be able to save changed options back to the INI, and I didn't see a way of doing that with boost.program_options.
Use boost::program_options. It's exactly what it's for. In one library you get command line options, environment variables options and an INI-like configuration file parser. And they're all integrated together in the Right way, so when then the user specifies the same option in more than one of these sources the library knows the Right priority order to consider.
boost::property_tree on the other hand is a more generalized library. The library parses the text stream into a uniform data model. But You need to do the real parsing -- that of making sense of the blob of data for your needs. The library doesn't know when to expect a parameter when it sees a particular option string, or to disallow specific values or types of values for a particular option.
After some digging around I think boost.PropertyTree is still the best solution because it gives me the capability to save the options after changing them from within the program which is a requirement.
There is a non-Boost possibility too. Config4Cpp is a robust, simple-to-use and comprehensively documented configuration-file parser library that I wrote. It is available at www.config4star.org.
I suggest you read Chapter 3 (Preferences for a GUI Application) of the Practical Usage Guide manual to read an overview of how Config4Cpp can do what you want. Then open the Getting Started Guide manual, and skim-read Chapters 2 and 3, and Section 7.4 (you might prefer to read the PDF version of that manual). Doing that should give you sufficient details to help you decide if Config4Cpp suits your needs better or worse than Boost.
By the way, the indicated chapters and sections of documentation are short, so they shouldn't take long to read.