I'm following getting started on main website. And I copy-paste:
middleman init my_new_mobile_project --template=html5-haml
Unknown project template 'html5-haml'
middleman init my_new_mobile_project --template=html5
Works...
Middleman 3.0.11.
I've just gone through that too, it seems the instructions for the html5-haml template are legacy, for a previous Middleman version. Current Middleman doesn't come with it, and the under development Middleman-HTML5BP-HAML template cloned to ~/.middleman/html5bphaml/ and used through middleman init my_new_project --template=html5bphaml has caused me problems, it installs an entire gemset and is dependent of older gems than the ones that were working with the provided templates.
The author says it's to be bundled with Middleman soon, so I expect the behavior of the template to be similar of the other ones when this happen.
Related
We're adding a QuickLook plug-in to our project.
Everything is fine until macOS trying to invoke our plug-in, at which point we're getting the beloved The bundle couldn’t be loaded because it is damaged or missing necessary resources error.
We've checked with otool -L on the plug-in's binary that all dependencies are in place, however as soon as the OS is asking our plug-in for a preview for the file type supported by us we get:
22/04/17 12:03:05,716 quicklookd[55323]:
[QL] Can't load plug-in at file:///Users/myname/Library/Developer/Xcode/DerivedData/The_Project-gpihzjouhxvifqcslmywktktizer/Build/Products/Debug/MyApp.app/Contents/Library/QuickLook/SomeQuickLookPlugIn.qlgenerator/:
The bundle “SomeQuickLookPlugIn” couldn’t be loaded because it is damaged or missing necessary resources.
The one thing we're not quite sure about is the dependency to our internal frameworks.
We've set up the plug-in similar to our main app, i.e. the private framework dependency resolves to:
#executable_path/../Frameworks/MyFW.framework/Versions/A/MyFW (compatibility version 1.0.0, current version 1.0.0)
..which would work OK if #executable_path were either the main app's binary or the plug-in's main binary as we copied the frameworks in both places in the bundle.
Any thoughts?
Ideally we would like the OS to tell us which dependency it failed to resolve -
is there any debug flag that can be set..?
As per https://www.mikeash.com/pyblog/friday-qa-2009-11-06-linking-and-install-names.html and http://www.dribin.org/dave/blog/archives/2009/11/15/rpath/ you should
set the Installation Directory for your referenced framework(s) to #rpath
in the app set Runtime Search Paths to #loader_path/../Frameworks
and in the QuickLook plug-in set Runtime Search Paths to #loader_path/../../../../../Frameworks as suggested by catlan -
that way you don't need to duplicate referenced frameworks inside the QuickLook plug-in
Compile, run, and everything should just work if everything else is set up correctly.
In addition you might want to check the code-signing settings in your plug-in to make sure there's no problems there.
One thing you can do is remove (or turn-off) code signing from your app and then see if it will load the plug-in…
To check if code-signing is the problem you can turn it off temporarily for your app using the Terminal to codesign --remove-signature YourApp.app and see if it works..
Run Search Paths should be #loader_path/../../../../../Frameworks because it is installed into Main.app/Contents/Library/QuickLook/QuickLookPlugin.qlgenerator/Contents/Mac/QuickLookPlugin, so we need to go five folders down from the #loader_path to find the frameworks folder.
Using the search I already found some great answers to similar questions, but still I am not sure if I understood it correctly.
From these answers I learned that dependencies are required to run the application while devDependencies are only required while developing (like unit tests).
But how about this: My application depends on jQuery, but during a build step (with the help of my devDependencies), everything is bundled into one file. In this case, should I list jQuery as dependency or as devDependency?
To make my point more clear take a module like this:
define(['jquery'], function($) {
// use jQuery in this module
})
Later on, this module will be compiled into somehing like application.build.js which then contains this module and the jQuery dependency.
Since the end result is the same, there doesn't seem to be a definite rule here, but I found a couple of discussions on the matter:
If you're building an application
https://github.com/webpack/webpack/issues/520
A browser app built by [insert build tool/bundler] has no runtime node dependencies, and thus all frontend dependencies should be listed as devDependencies. The dependencies vs devDependencies naming convention stems historically from node being a server side package manager (...) It is as far as I can tell harmless to list frontend dependencies under dependencies, but it is wrong.
(...) as a general recommendation for everyone, move everything into devDependencies until it is actually needed under dependencies.
If you're building a library:
https://github.com/inuitcss/inuitcss/issues/225
In many frontend projects, all code served to the browser is compiled, there are no runtime dependencies. This would mean that there are no dependencies, only devDependencies – all dependencies are included in the build done during development.
One could also argue that dependencies are required for development as well, so it would be okay to list everything unter dependencies.
I think the fact that we have the optional distinction indicates a reasonable way to use them. It makes sense (to me) that the dependencies designation would represent the 'minimum viable' code to use and as an indicator of what's nonessential for something to work.
As I see it, anything that goes on to become part of the production code is a dependency.
Epilogue
Personally, I agree more with the last quote. It makes sense that dependencies tells us what the application code needs to run, and devDependencies what the developer needs to build/deploy/whatever the application/library.
One caveat though is that if someone npm installs your library to use the bundle as a module in their own application, they will download a lot of dependencies they don't actually need.
I upgraded my MVC 4 app to MVC 5 a couple of days ago following these instructions and now I'm getting the following error. I updated DotNetOpenAuth to the latest bits using Nuget (v4.3.3.13295) but it still throws this error.
How do I fix this?
Inheritance security rules violated by type:
'DotNetOpenAuth.Messaging.OutgoingWebResponseActionResult'. Derived
types must either match the security accessibility of the base type or
be less accessible.
Solved this finally. Turned out that I needed to make some changes to the source code of DotNetOpenAuth and re-compile it. This wasn’t easy at all since the source code won’t compile after downloading from github. I had to spend ~3 days trying various things and learning the build system meshed into DotNetOpenAuth’s project files until I finally got it to compile. Seems the author of this project has abandoned it. See more about this issue here.
Download the 4.3 code base using this command line: git clone -b v4.3 https://github.com/DotNetOpenAuth/DotNetOpenAuth.git
Edit the /src/version.txt and change it to 4.4.0. This makes this version higher than the official Nuget release so that installing Nuget packages don’t attempt to install old versions of DotNetOpenAuth assemblies from its repository.
Remove all instances of the following string from all AssemblyInfo.cs files under the /src/ directory.
[assembly: AllowPartiallyTrustedCallers]
I had to mess around with the Microsoft.Contracts reference in two projects and point it to /tools/Contracts/PublicAssemblies/v3.5/Microsoft.Contracts.dll and then use a using alias to get classes from this assembly to resolve properly. A few Requires.NotNull() lines refused to compile so I just commented them out… c'est la vie..
Run the following command to skip verification of these assemblies: sn.exe -Vr *,2780ccd10d57b246
Once the assemblies were built I referenced those, re-added Microsoft.AspNet.WebPages.OAuth 3.0 from Nuget, rebuilt my solution, and finally my app is up and running on MVC 5.
I've now been trying to get MinGW-w64 to work on my system for several days, mainly because it has a more recent GCC version, but I either set things up wrong or there's some strange problem with MinGW-w64 itself.
I've now downloaded i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb, unpacked it to C:/Dev/mingw-ruben and added the path C:/Dev/mingw-ruben/bin to the $PATH environment variable.
What I'm trying to build is SFML 2 which comes with a CMake file. Running CMake will work just fine, the compiler gets recognized and passes all test. CMake also finds the ar.exe in the C:/Dev/mingw-ruben/binfolder. After generating the MinGW Makefile I switch to the windows command line and run mingw32-make install.
There's where the problem happens, I get the error:
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libopengl32.a: No such file or directory
Or for the network library
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libws2_32.a: No such file or directory
The error seems quite obvious and on check there really is no libopengl32.a or libws2_32.a in mingw-ruben/lib/, but the files is actually located in C:/Dev/mingw-ruben/i686-w64-mingw32/lib.
Now How can I tell ar/make/cmake to not only search in the mingw-ruben/lib directory but also in the mingw-ruben/i686-w64-mingw32/lib?
Would it be a good idea to copy all the content from the i686-w64-mingw32 subfolder to the mingw-ruben root folder?
As a side note: I can call mingw32-make install again and the procedure will continue but up on trying to link my application against SFML, I run into many unresolved symbol errors for the glXYZ functions from within SFML.
Further information: I'm on Windows 8 x64, but I think that doesn't really matter and yes I've tried MSYS but it doesn't resolve any of my issues.
Am I doing something wrong? Do I have to configure things specially?
January 2015 Edit
Now that SFML 2.2 has been released, this is no longer an issue and you have to link SFML's dependencies yourself when linking static.
January 2014 Edit
As of commit 165f2b1888 and f784fe4c07, which is included in the stable version SFML 2.1, MinGW-w64 compilers are supported.
However while discussing further with different parties it came to light, that the sfml_static_add_libraries marco a rather ugly hack was. In short it unpacked the static dependencies and included their obj files into the SFML library itself. This was most noticeable an issue, when trying to use your own version of GLEW, which failed since SFML was using its internal one already. The issue was brought to the forum and was pushed around for quite a bit, until Laurent finally gave in and went with the proper way of linking dependencies, which means you have to link them now on your own.
As of commit dbf01a775b, which is not included in the stable version of SFML 2.1, one has to link the SFML dependencies in the finally application, when linking statically against SFML.
Original
After some chat on the IRC we've figured it out.
It has nothing to do with MinGW but it's all SFML's fault. To reduce the dependencies list for SFML while linking statically the developer decided to manually extract the symbols from each library (opengl32, ws2_32, ...) which obviously isn't how one does things and violates some ODR rules. The actual error then occurs because the developer assumed that the library will be in the folder mingw/libbut with MinGW w64 it's located in a seperate directory mingw/version/lib and so ar.exe didn't find the library.
Solution
Removing the call to the sfml_static_add_libraries macro and then recompile. Afterwards you'll have to link all the dependencies for static linkages, like it should be.
I think it may be well a problem of the gcc distribution you downloaded.
A bit of light into the problem gives ruben's question here:
https://unix.stackexchange.com/questions/45277/executing-binary-file-file-not-found
that seems to me related to that (although it is about linux and not win)
I was having a similar problem (the name of the missing file was different) few months ago with gcc 4.7.0 linux->win crosscompiler. So until now I lived with the standard ubuntu mingw-w64 package and only yesterday I gave another try to i686-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar.xz and it works without issues in otherwise same environment where the previous version was failing with "..ar.exe: ... no such file". Sometimes I develop also in windows, then I use http://www.mingw.org/ that was for me much easier to setup in Win. It supports only 32bit target but for my project it is sufficient.
Here is my situation. I have a play app which uses the guice module. In order to work with the guice module:
I installed it using play install guice. This installs it in the $PLAY_HOME/modules which is fine by me. I don't want to edit the module files in any way whatsoever.
Then I declared the module in my dependencies.yml like so: - play -> guice 1.2
Within my app, I ran play dependencies, and this resoles the module just fine and creates a modules/guice-1.2 file that references the guice module.
The issue is that the content of that file is something like the following: /some-absolute-path/play-1.2.x/modules/guice-1.2.
That works fine when working locally for development. But when I want to move to a production server, with a different install of Play! (i.e. with a different absolute path to it) it will obviously fail.
So what's the best way to deal with this?
For now I've resorted to declaring the module in the application.conf file like this: module.guice=${play.path}/modules/guice-1.2.
Unfortunately the ${play.path} magic doesn't seem to work on those generated files.
By the way I use version 1.2.3 of Play!
you should try with ${application.path} in your dependencies.yml file, like in this example
require:
- play -> crud
- provided -> DateHelper 1.0
repositories:
- provided:
type: local
artifact: "${application.path}/jar/[module]-[revision].jar"
contains:
- provided -> *
see this question: How can I specify a local jar file as a dependency in Play! Framework 1.x
When you run in production you will either resync the dependencies (via play deps command) with the local installation of Play or in some scenarios you can precompile everything and then there will be no issues with the paths.
That second scenario is the one with Heroku, for example.
It's not answer to your question, but I have faced with same issue.
I don't want to call resync the dependencies on production.
I don't want to ask my team members, install special module.
I don't want to commit file containing absolute path with module location.
The only workaround that I find: do not install module in Play! application, just include jars which use this module manually. play-guice.jar should be included as #opensas suggested, aopalliance and com.google.inject as regular dependencies in dependencies.yml.
The funny thing, that resync dependencies is also deleting .svn files, so back-up its before calling this command.