I'm using Google's closure compiler (set to compilation_level=ADVANCED_OPTIMIZATIONS) to successfully minify/obfuscate my javascript code (I'm currently doing this semi-manually with a Sublime text plugin).
The vast majority of my javascript is in a single .js file, but of course if I obfuscate this code, and there's other snippets of javascript in my project's html files (perhaps referring to pre-obfuscation function names), then I'm going to run into problems.
What's the best approach to dealing with this dilemma? Ideally I could run a whole project through the compiler which would recognise javascript inside html files and obfuscate them in a consistent way.
Export the functions that you need to call from HTML code, those will not be renamed (minified) by the compiler. Either use the #export tag as part of the type definition, or call goog.exportSymbol or goog.exportProperty after they are defined. See the section in this wiki page about #export.
See the section Solution: Export the Symbols You Want to Keep on the page about Advanced Compilation and Externs for discussion and yet another way:
function displayNoteTitle(note) {
alert(note['myTitle']);
}
// Store the function in a global property referenced by a string:
window['displayNoteTitle'] = displayNoteTitle;
You can use obscure names for the things that are exported if you need to. If you have a lot of code in the html files, move that code to functions in your single file and call those functions from html. Closure Compiler will not compile code that is inside an html file.
Related
I feel like I'm missing some key idea with this one.
I have a library that I'd like to create a CMakeLists.txt file for. I want to link against it with different applications.
This library expects a conf.h file to be defined. The application has to provide this. The library expects it. What is this relationship called?
My current solution in CMakeLists.txt is to have a variable like:
...
target_include_directories(lib PUBLIC
${CONF_DIR}
)
And then have CONF_DIR be defined by the application. This is uncool, because I can't have multiple applications linking against it.
The only other alternative is to keep a copy of the entire source library inside the application folder, which is also uncool.
I'm looking to maximize reusability. How do I approach this?
Side note: For anyone who's familiar, the library in question is STM32Cube's HAL library, and the pesky file is stm32h7xx_hal_conf.h.
This is a very common approach, when a library requires configuration. FreeRTOS would be another example.
I don't see the issue with modifying the target_include_directories for the library from the App's CMakeLists.txt.
Usually, I create a function to handle the library set-up. The call site would look something like this:
add_stm32_hal_lib(
PATH drivers/STM32H7xx_HAL_Driver
EXTRA_INCLUDES path/to/config
)
# ...
target_link_libraries(app PUBLIC stm32_hal)
The contents of the EXTRA_INCLUDES parameter get shoved into target_include_directories of the static library.
You can't do anything about this, so you'll have to copy the library code.
The header file is used during library compilation stage, so its code ends up being hardwired into the final binary. Because of this, if you want to change some parameters from the header, you need to recompile the library from scratch.
Ideally, the library should be rewritten in such way, that all parameters that are contained in the header can be set up dynamically, during the runtime, using some additional configuration API.
A colleague gave me a modified version of a shared library where he added a GTK widget.
When inspecting the shared library file I see that the new widget functions are defined as local and not global.
I have tried to set the visibility attribute of GCC on the function (after the declaration itself, before the semicolon), it has G_BEGIN_DECLS around it and the same common headers and defines as other files in the library that are exported properly.
Is there a linker command line option I may be missing? A list of files that "can" export that is used by gcc, perhaps another definition for exported functions?
When inspecting the shared library file I see that the new widget functions are defined as local and not global.
By default, all symbols in a shared library are exported (unless you compile with -fvisibility=hidden or protected.
Since observe that your symbols are LOCAL, it is a good bet that your link command uses a linker version script to control symbol visibility (to hide all symbols except ones that are explicitly exported), and that you have not modified that version script to add your functions to the export list.
Look for -Wl,--version-script=... on your link command line, and modify the version script appropriately.
See also this answer.
I've found out that the library uses a regular expression to filter exports (the -export-symbols-regex switch), adding another regular expression made the symbols properly exported, now I everything is linking properly.
I'm working with pocketsphinx. It comes in 2 dlls. sphinxbase.dll and pocketsphinx.dll. pocketsphinx.dll calls on functions in sphinxbase.dll. I'm going to be calling functions in both. I'd like to know the easiest way to merge both source files into producing a single dll.
I've tried this before but I run into the problem of pocketsphinx using sphinxbase leading to a warning/error about importing functions I'm trying to export.
What's the common solution to get around this?
Should I remove the dllexport tags from sphinbase and then wrap those functions inside other functions that I then export?
Example
//inside sphinxbase
SPHINXBASE_DLL_EXPORT
void sphinxbasefunc();
//inside pocketsphinx
POCKETSPHINX_DLL_EXPORT
char* decode(ps_decoder_t decoder)
{
...
sphinxbasefunc();
...
}
Then I would remove the SPHINXBASE_DLL_EXPORT macro and create a wrapper that I would then export.
//inside sphinxbase
void sphinxbasefunc();
WRAPPER_DLL_EXPORT
void sphinxbasefunc_wrapper() { sphinxbasefunc(); }
This solution I think is naive on my own part though. Theres dozens of functions I would need to wrap if I took this route.
One thing to realize is like an exe, a dll is just a collection of one or more object files bound into a package. Combining object files into dlls/exes is the linker's job. If you want to combine your two dlls into one, combine the object files that make up your two dlls into one dll. When you do that your references will no longer be to dlls, but directly to the objects themselves (source code changes will be required, but mostly this is removing dllimports), so it should be a much more direct process (include the header, make sure the object is included in the link). You only need to export those functions required by consumers of the final dll. Basically put the source for both dlls into one project. I'm assuming of course that you have the source for these dlls (which is how it appears from the url given). If you end up with circular dependencies you may have to create some forward declarations or additional header files to keep the compiler happy.
What's the simplest way to find the path to the file in which I am "executing" some code? By this, I mean that if I have a file foo.py that contains:
print(here())
I would like to see /some/path/foo.py (I realise that in practice what file is "being executed" is complicated, but I think the above is well defined - a source file that contains some function that, when executed, gives the path to said file).
I have needed this in the past to make tests (that require some external file) self-contained, and I am currently wondering if it would be a useful way to locate some support files needed by a program. But I have never found a good way of doing this. The inspect module sounds like it should work, but you seem to need a class or function that is defined in that module.
In particular, the module instances contain __file__ attributes, but I can't see how to get the "current" module. Objects have a __module__ attribute, but that's the module name, not a module instance.
I guess one way is to throw and catch an exception and inspect the contents, but that seems like hard work. Surely there is a simple, easy way that I have missed?
To get the absolute path of the current file:
import os
os.path.abspath(__file__)
To get content of external file distributed with your package you could use pkg_util.get_data()(stdlib) or pkg_resources.resouce_string() (setuptools) to support execution from zip-archives or standalone executables created by py2exe, PyInstaller or similar, example.
I am trying to use Eclipse and NetBeans for programming in C (not C++). Is there a feature/plugin for them which automatically keeps the source and header files in sync?
As in, when I implement a function in the source file, does it automatically insert the correct lines in the header file?
I did look at solutions like lzz, but they are not what I am looking for.
Eclipse CDT allows you to write a prototype in the header file, and automatically add it to the C file.
Instructions
Add function prototype to .h file void foobar()
Select the function name "foobar" (try double clicking)
In the toolbar click Source -> Implement Method
Wizard it up
Thats probably the best you're gonna get out of the box
Agree with approach proposed by Ryu. In C, I would not automatically create declarations in headers. This should be an explicit action making public some symbol from the C module.
However if declaration/implementation are already setup and you want to modify any of them, I imagine that with Eclipse you may want to use Toggle Function Definition in a possible workflow where you copy in clipboard intermediate toggling results and paste them later over the changed declaration or implementation declaration.
Also use rename refactoring intensively when you change things.