I'm trying to bundle a ESM source file that includes dynamic imports like e.push(import("./polyfills/dom.js")). Not my code, so I can't change it.
With --experimentalCodeSplitting, Rollup would try to code split, but I actually want a single all-in-one bundle.
Is it possible with Rollup to include all these imports in one file?
It turned out that I was using an older version of Rollup (0.58.2). It works fine with never versions (0.60.1).
Related
Programmatically I want to get all dart files available to import.
How can I achievement this? (programmatically)
In which environment do you want that?
If it's for a single Pub package, ensure that dart pub get has been run, then parse the .dart_tool/package_config.json file and find the roots of all the packages. Then search through those directories for all dart files that are not part files (does not start with part of ...;). The rest should be Dart library files which can be imported.
If you only want the packages that can be imported from inside lib/, you may want to parse the pubspec.yaml file too, so you can ignore the dev_dependencies.
Then you may also want to list the available dart:... platform libraries. Which are available depends on which platform you compile for. You need to figure that out somehow, then you should just keep a list for each platform.
I am trying to use Berkeley's SPICE tool in an iOS app, but am having trouble compiling it for iOS.
It is a command-line program that I can call from a terminal like:
./spice3f5 <arguments>
Which works well, and I would like this functionality in my iOS app, but I don't think I can just copy the executable over to Xcode and call it from Swift.
I've done some research and found the following:
There is an updated version of SPICE called ngspice, which is relatively new (2014 release)
I'm fairly sure there are apps out there than have used either SPICE or ngspice, so I'm sure it can be done somehow.
I have read an article about a guy who says that ngspice has been compiled as a shared library(ctrl+f "ngspice"), and he made an app with it. I have emailed him but he unfortunately he has not responded.
The reason I am asking here is because when googling for "ngspice iOS", I came across this thread which has a lot of smart people trying to compile a static library, which seems way out of my scope. I learned that dynamic libraries are allowed as of iOS8. So would it be easier to compile a *.dylib than it is a static library?
How would I goabout using ngspice or SPICE in an iOS app?
Thanks
The difference between a static and a dynamic library is essentially where they live, a static library will live inside the binary of your app, and an dynamic library will live on the system (iPhone) that runs your app. there isn't much difference as far as difficulty goes. If you wanted to go the dynamic route on os x for example, you might compile a .dylib file in a separate project first. Then copy your new .dylib file into /usr/lib or a similar location that is part of your system's path. Then you would need to copy the associated header files that know how to talk to your new .dylib file into your /usr/include folder. At this point you could import said header files in xcode using angle brackets like so:
#import <my_dylib_header_file.h>
in static world however, you would simply drag your .dylib file into xcode then copy the associated header files into your source folder and then import using quotes like so:
#import "my_dylib_header_file.h"
the advantage of doing the import statically is that the library becomes baked into your final product, as opposed to a dynamic link, which will require that the dylib is installed on the system prior to the binary being able to run properly (think DLL's on windows). The disadvantage of a static import is that the final binary is larger, as it contains more code.
The advantage of a dynamic import is that the binary is smaller, and dylib can be updated without updating the binary itself.
However based on your questions I don't think any of this matters for your project. You have the source code. Which means creating a dylib is entirely unnecessary for your purpose, you can treat the source code like a static library by simply adding it to your xcode project. If I were you I would add the spice source code to my xcode project and forget about creating a dylib. From there I would import the files and make calls to them from swift. There are lots of threads out there that explain how call c functions or objective-c classes from swift so I wont go into that here, instead I'll refer you to another answer: Swift: How to call a C function loaded from a dylib
I have code for a VST plugin and need to port some of it to an iOS app.
I have tried building the OSX version and using the lib.a and it doesnt work. When I open the iOS version of it, Xcode shows that it is missing the tagret.
If I copy the code directly into Xcode with all the JUCE modules, and I set the header search paths, I get compilation errors on things like no such type for String
After this latest JUCE update, Xcode would give the same errors until I updated the JUCE file itself, so I think the JUCE build settings or configuration of the new version is doing something differently. How can I get this code into a different Xcode project, so that I can use it?
Can I compile it as a library and use the objects through the header?
JUCE is designed to be included in projects generated by the Introjucer / Projucer (the JUCE project management tool). Without this, the correct preprocessor definitions will not be set up.
If you really needed to include JUCE source code inside your program, you could manually set up these preprocessor definitions (take a look at the AppConfig.h header from a generated project to get an idea of how much work this will be), but you'd really be going against the normal "JUCE way".
Simply including the headers and linking against the library will not work without considerable effort, as the include structure is ... odd ... and there isn't any library to link against directly anyway (the generated projects contain all the JUCE source normally, so there's no need).
Adding the JUCE source files (i.e. .cpp and .mm) to be compiled in a project directly will result in compilation errors, as they need to be compiled in a very specific order which is mandated by the header file (the header files #include certain implementation files after setting up their dependencies).
In short, if you can at all I would advise generating the project with the Projucer and adding other source files in as you need them, rather than the other way around.
I’m trying to use JavaFXPorts and RoboVM-cocoatouch but I can’t use the native stuff from RoboVM like UIButton.
I have the following dependencies in my build.gradle file:
classpath 'org.javafxports:jfxmobile-plugin:1.0.0-b5'
classpath 'org.robovm:robovm-cocoatouch:1.0.0'
And I'm trying to import org.robovm.apple.uikit.* but eclipse can't find the Packages.
What I have to do that I can use JavaFXPorts and the native stuff from RoboVM?
The short answer:
you need to create a folder src/ios/java in which your iOS specific source files should be located. The source files within this folder automatically have the correct classpath set, so you can use the RoboVM classes there.
The long answer:
In addition to the default main source set, the jfxmobile plugin also adds a source set for every platform the plugin supports: android, ios and desktop. Each source set has a src/PLATFORM/java and src/PLATFORM/resources directory which contains the platform specific source files and resource files respectively.
Platform independent code must be written inside the folder src/main/java, while platform specific code must be written inside the matching platform sources folder. For instance, in your case, iOS code should be put inside the src/ios/java folder.
The plugin also makes sure that the dependencies are correctly configured for each source set. Also, when you are for instance generating your IPA, it will only contain the class files from the main and ios source sets.
For more information about the structure of a jfxmobile project, look at the Structure section on this webpage: http://javafxports.org/page/Setting_up
You can read more information about gradle source sets in the java plugin documentation: http://gradle.org/docs/current/userguide/java_plugin.html
I am trying to understand Dart's recommended project structure and not seeing the "forest through the trees".
So, if my project is intended to be a reusable library, say, a logging framework of some sort, then if I understand the above link correctly, I want all of my development to be under a lib and lib/src directory.
But what if I am building a web app? Where do my Dart source files go? Under packages? Specifically:
Where do I place Dart source files for a web app (not a lib)?
Are my web app's "packages" just directories that are logically organized similar to Java packages?
Does Dart recommend a 1-class-per-file convention for its source code?
1)
your_app_package/web
your_app_package/web/src/xxx
static content like jpg, css go to
* your_app_package/asset
2) the packages directory is maintained automatically. You configure in the file pubspec.yaml which 3rd party libraries you want to use and then call pub get or pub upgrade and the packages directory is updated automatically (the Darteditor does this automatically when you update pubspec.yaml).
3) not that I know of.
I had some problems putting additional classed in the code file of a Polymer element though. But I guess this is just a temporary limitation of Polymer.