How third-party libraries in Lua usually handled?
For example, I want to use the HUMP library for my LÖVE application.
What should I do then? Is there any popular package manager? Or should I just place libraries under "vendor" / "libs" directory in the project's root folder?
Lua uses a package manager called LuaRocks.
However, HUMP, and most other third party libraries for LOVE do not have a rock (package) for LuaRocks, and thus cannot be installed/handled that way. There is no definitive convention for including 3rd-party libraries in a LOVE project. It's usually up to the project developer. However, there is a Thread on the forum where people talk about how they organize their projects that should be of use to you.
Related
i am new to Unity and i am try to understand plugins. I have got the difference between a managed plugin and a native plugin, but what is not very clear to me is:
what is the difference between a plugin and a dll? what should i expect to find in an sdk to make it usable in my unity project?
Thanks a lot
To expand on #Everts comment instead of just copying it into an answer, I'll go a little into details here
What is a plugin?
It's a somewhat vague word for a third-party library that is somehow integrated with the rest of your game. It means that it neither is officialy supported by Unity, nor is it a part of your core code. It can be "plugged" in or out without altering its internals, so it must provide some kind of API that can be used by the game code.
For example, you'll find many plugins that handle external services like ads, notifications, analytics etc. You'll also find a couple of developer-tools that can also be called plugins, like tile-based map editors and such.
Plugins come in many forms - DLL files are one example but some plugins actually provide full source code for easier use. And of course, other plugins will provide native code for different platforms, like Objective-C for iOS or .jars for Android.
So to answer your first question:
DLL is simply a pre-compiled source file that can be a part of a plugin
A plugin is a whole library that can consist of multiple files with different formats (.cs, .dll, .jar, .m etc)
What do you need to use an sdk?
First of all - documentation. Like I said before, and like you noticed yourself, not all plugins give you access to the source code. And unfortunately, not many sdks have extensive and developer-friendly documentations so it can be a tough task to actually understand how to use a given sdk.
Secondly - the code. Many sdks give you some kind of "drag & drop" library, a single folder with all the neccessary files inside that you simply add to your Unity projects. I've also seen sdks that use Unity packages that you have to import via Assets > Import Package > Custom Package.
Once you have the code and documentation it's time to integrate it with your game. I strongly recommend using an abstract lyer in your game as, in my experience, you often have to change sdks for various reasons and you don't want to rewrite your game logic every time. So I suggest encapsulating sdk-related code in a single class so that you have to change only one class in your code when switching from, say, one ad provider to another (and keep the old class in case you need to switch back).
So you basically need three things:
Documentation (either a readme file or an online documentation)
The code (precompiled or source)
A versatile integration
I am building a Spring project with Bower to manage client libraries. I am interested to know what is the best practices way to expose those libraries (or any sort of client libraries managed by a package manager) to the web client.
I can see that I can use a .bowerrc file to choose where to install the files. I could have them install into a static resources folder, one where each of the files installed would be accessible to http requests. It struck me as a potential code smell, however, to expose all the files, instead of the ones that I specifically need.
I could copy individual files into such a directory, or adopt an automated solution to do the same. If this is not considered necessary, however, I would prefer not to expend the effort.
Which of these, or any other solution (if any) is considered the clear best practices way to do this and why? (Please provide a reference to support your answer.) To be clear, I am not interested in individual opinion, but rather if there is a known, clearly preferred, solution.
After looking at what a lot of projects and tutorial suggest, it seems that the clear way to do this is the following:
Use a framework like Grunt or Gulp to separate "built" code from source code. Built code, in this case refers to code that is copied, minified, and/or concatenated into a separate folder. The Grunt or Gulp configuration file should include all application code, as well as select source files from bower components. The running application should reference only these "built" files. The directory of "built" client-side code should be served statically by Spring.
I'm getting to the point in my Dart project where I need to start putting things in separate files/packages. My project has 2 generic areas of concern, so it seems like there needs to be 2 libraries, call them libA and libB, and then some generic code that draws on both of them. Ideally, I need something between one file and full-on separate projects.
I don't think I'm ever gonna want to export them as separate Pubs, but maybe... Does that mean they should be libraries and not packages? Is there even a difference between libraries and packages in Dart? Do I need 3 different full projects? I hope not.
I guess I'm looking for a way to have several local packages in the same project.
What's the SIMPLEST way to structure everything?
If your code will only be relevant to one project, use one package and multiple libraries. For instance, consider a tower defense game: there will be one package for the whole game, but multiple libraries each dealing with their own areas of concern (enemy lib, tower lib, etc.).
If your code will be relevant to multiple projects but only for your projects (and not the general public), split the code into multiple packages, use local or github pub dependencies, and do not publish them on Pub:
dependencies:
transmogrify:
path: /Users/me/transmogrify
See Pub Dependencies for more info.
Continuing the above tower defense example, this would be useful for something like a game studio splash/intro screen. You would want to reuse this across multiple games, but it is not useful for anyone but you.
Finally, if the code can be used for multiple projects, and is of interest to other developers, publish it as a Pub package. For instance, a game engine would be useful to other game developers.
I'm aware of Cocoapods. However this isn't very useful for commercial use because we don't want to deliver source code.
We want to be able to deliver compiled libraries. But use them in our own (and client) projects, just like with Cocoapods. And just like maven does with jar files and the suchlike.
Is there anything which provides this (or similar) functionality. It seems very shortsighted of Apple not to include anything like this, or the ability to support anything like this, within XCode.
Thanks
In our Java applications we typically use the maven conventions (docs, src/java, test, etc.). For Perl we follow similar conventions only using a top level 'lib' which is easy to add to Perl's #INC.
I'm about to embark on creating a service written in Erlang, what's a good source layout for Erlang applications?
The Erlang recommended standard directory structure can be found here.
In addition you may need a few more directories depending on your project, common ones are (credit to Vance Shipley):
lib: OS driver libraries
bin: OS executables
c_src: C language source files (e.g. for drivers)
java_src: Java language source files
examples: Example code
mibs: SNMP MIBs
Other projects such as Mochiweb have their own structures, Mochiweb even have a script to create it all for you. Other projects such as Erlware overlay on the standard structure.
Another critical directory is the priv directory. Here you can store files that can easily be found from your applications.
code:priv_dir(Name) -> string() | {error, bad_name}
where Name is the name of your application.
Erlware is changing that - in a couple of days the Erlware structures will be exactly that of Erlang OTP. Actually the structure of app packages is already exactly that of OTP and as specified above. What will change is that Erlware installed directory structure will fit exactly over an existing Erlang/OTP install (of course one is not needed to install Erlware though) Erlware can now be used to add packages to an existing install very easily.
Cheers,
Martin