I'm doing mostly webdevelopment and recently decided to give sublime 2 a try.
For my typical projects I have a Makefile with multiple targets. (E.g.: javascript --> compress javascript, deploy --> upload to server, style --> build css from less, coffee --> compile coffeescript to javascript, etc.)
Sublime recognizes the make file and run the 'all' target works perfectly fine. But for large projects running all the stuff takes far to long so I would like to configure sublime, so it build only a specific make target.
Is there any way to configure Sublime to run only the make targets I want. Is there any possibility to do this with file in the project root (and tracked via git), so the build would even work on another computer?
I'm not sure if this is what your looking for but check out this forum, may give you a bit of an insight into multiple builds:-
Sublime Forum: multiple commands in build system?
if not then you could look and ask on the forums there, it will be more specialized for these sorts of features :)
This is from there and may be what your looking for?
:- "Unfortunately, there is no support for multiple commands in a build system. I ran into this issue when working with java. Your best option is to make a bash file with the commands and have a build system that runs the bash file. I'm not a expert when it comes to build systems, so that's as far as I can help.
Hope that points you in the right direction."
so maybe you can point at the specific "make" commands that you want to use...
With the current state of Sublime it is not possible.
Related
I'm creating a RN app that is meant to be some kind of wrapper. It should have multiple targets (like in Xcode) and all its content (images, text, etc.) should be target dependent. Unfortunately, I cannot find any useful informations about how to achieve this without opening Xcode or Android Studio project and create those targets manually (like here). Is there any other solutions for this?
I was still struggling with described problem but I finally found a solution. It's not easy, needs writing a bit of boilerplate code and looks more like a workaround but I hope it will help someone in the future. What I did is I have completed my wrapper app with the resources for one of my targets so I can have visual effect. In the project's root directory I've created a folder with subfolders for each target. Inside each I have put files (images, source code files, other assets) that are target-dependent. Then I've created bash script that takes one argument - target's name. Based on it, it replaces all the target-dependent files from target's subfolder to the original file's destination in the project structure. In this proces all meta-data informations are also replaced so after firing .sh file I can build the app and upload it to both stores. It's really time consuming to create all these apps separately and publish them and it's maybe not the best solution, but at least it works!
On android, you can edit build.gradle files, java or properties, without having to launch Android Studio (which simply uses Gradle)
You can build different type flavours by only changing app/build.gradle
On iOS, that's another story. Project file (.pbxproj) is a mess,and other Workspace/Scheme files are not easy to read or script. So XCode is the way to Go.
I tried to have dynamic target & Info.plist, there are tools to script that like PlistBuddy
in the end, I saw there are many ways to launch a React Native app for developpers. Some prefer the command line, and only VSCode.
Others want to play with native IDE.
By the way, native IDEs are VERY useful.
e.g. : you want to fine-tune your application performance, using XCode view hierarchy debugger or android Studio Layout Inspector (and be sure you don't use to many views), or use any other performance tools these IDEs offer...
In the end, I used react-native-config along with multiple almost similar configs (Info.plist < target < Scheme for each), here's a post giving an overview of the setup.
I am developing an OS for embedded devices that runs bytecode. Basically, a micro JVM.
In the process of doing so, I am able to compile and run Java applications to bytecode(ish) and flash that on, for instance, an Atmega1284P.
Now I've added support for C applications: I compile and process it using several tools and with some manual editing I eventually get bytecode that runs on my OS.
The process is very cumbersome and heavy and I would like to automate it.
Currently, I am using makefiles for automatic compilation and flashing of the Java applications & OS to devices.
All steps, roughly, for a C application are as follows and consist of consecutive manual steps:
(1) Use Docker to run a Linux container with lljvm that compiles a .c file to a .class file (see also https://github.com/davidar/lljvm/tree/master)
(2) convert this c.class file to a jasmin file (https://github.com/davidar/jasmin) using the ClassFileAnalyzer tool (http://classfileanalyzer.javaseiten.de/)
(3) manually edit this jasmin file in a text editor by replacing/adjusting some strings
(4) convert the modified jasmin file to a .class file again using jasmin
(5) put this .class file in a folder where the rest of my makefiles (the ones that already make and deploy the OS and class files from Java apps) can take over.
Current options seem to be just keep using makefiles but this is a bit unwieldly (I already have 5 different makefiles and this would further extend that chain). I've also read a bit about scons. In essence, I'm wondering which are some recommended tools or a good approach for complicated builds.
Hopefully this may help a bit, but the question as such could probably be a subject for a heated discussion without much helpful results.
As pointed out in the comments by others, you really need to automate the steps starting with your .c file to the point you can integrated it with the rest of your system.
There is generally nothing wrong with make and you would not win too much by switching to SCons. You'd get more ways to express what you want to do. Among other things meaning that if you wanted to write that automation directly inside the build system and its rules, you could also use Python and not only shell (should that be of a concern though, you could just as well call that Python code from make). But the essence of target, prerequisite, recipe is still there. And with that need for writing necessary automation for those .c to integration steps.
If you really wanted to look into alternative options. bazel might be of interest to you. The downside being the initial effort to write the necessary rules to fit your needs could be costly. And depending on size of your project, might just be too much. On the other hand once done with that, it'd be very easy to use (apply those rules on growing code base) and you could also ditch the container and rely on its more lightweight sand-boxing and external rules to get the tools and bits you need for your build... all with a single system for build description.
I have found that Edit-and-Continue does not work in linked files. I am working on a suite of 8 different utilities (C# winforms) and they all share several common classes, which have been added to each utility project as a linked file. I can set breakpoints in the linked files, and step thru the code in them, but not edit. When I try, I get the error "Changes are not allowed if the project wasn't built when debugging started." I've made sure to perform a clean and build before running, but that doesn't help. I've had some of my colleagues try it on their machines with the same results. These linked common classes are key to each of the utilities and where much of the code resides. Not being able to edit-and-continue is making debugging much more difficult and tedious. Edit and continue works in the non-linked non-common files. Can anyone suggest a workaround? I have considered merging all 8 utilities into one, but they each take different command line parameters and are really intended to be used individually.
I develop web applications (in PHP, JavaScript, CSS) using Geany, so I'm in no need for compile, run, make... functions of Geany. Yet Geany is spamming my project directories by creating geany_run_script.sh file in every one of them.
The question is: What can I do to make it stop doing this?
You don't need it. You can configure it via Preferences->Terminal->Execute programs in VTE + Don't use run script. This will need you to have libvte installed and will not work at Windows.
These scripts are generated once you hit F5 e.g. for previewing it inside a browser.
I'm currently using Terminal to compile with MXMLC. Each time I want to compile I need to introduce the file name, and the first time I open Terminal I also need to specify the path of the file.
I'm sure there is a faster way to do this. I'm completely new to programming, and I haven't explored the possibilities of command line and executable files in Mac OS X.
I was wondering if there is a way to automate this task, like a executable file that automatically opens terminal and inputs the lines necessary for the compilation. I double click it and the compiled file is deployed. Is it possible?
Thanks for your time.
There are lots of ways to compile a Flex application, but basically it should boil down to the following options:
let your IDE do it for you; there is no way to automate this process of course
use the command line interface (CLI) (that's what you're doing); I suppose you could write a batch file or a shell script or whatever Mac equivalent may exist to automate the process a little more
use ANT and the Flex ANT tasks that come with the SDK: http://livedocs.adobe.com/flex/3/html/help.html?content=anttasks_1.html; this is basically just a wrapper around the CLI, but it allows you to do other tasks like copying files, packaging, etc.
use a build and dependency management tool like Maven or Gradle to automate everything. Both of these tools are primarily targeted at Java building, but they both have a plugin for building Flex applications:
Maven > FlexMojos
Gradle > GradleFx
The choice is up to you of course, but I personally prefer GradleFx for its simplicity and comprehensiveness. (Disclaimer: I actually liked it so much that I became a contributor to the project, so I may no longer be impartial ;) )