i am looking for a build tool that allows me to store the build tool with additional pre and postscripts as well as the build configs in folders separated from the source code.
Most build tools i tried work with config files directly in the source code folder.
Could you recommend something?
I know that it sounds like i am missusing the concept and should simply insert config files in the source code folder. Yet the reasoning behind this will blow up this post without adding a lot of value.
SCons can do it several different ways.
Though Repository() might be the simplest.
See: https://scons.org/doc/production/HTML/scons-user.html#idm46358268990080
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 writing a Go command-line tool that generates some files based on templates.
The templates are located in the Git repository alongside the code for the command-line tool itself.
I wanted to allow the following:
The binary, wherever it is called from, should always find the templates directory.
The templates directory can be overriden by the user if need be.
Since this is a Go application, I went with something like:
templateRoot := filepath.Join(
os.Getenv("GOPATH"),
"src/github.com/myuser/myproject/templates",
)
But being rather new to Go, I wonder if this approach is reliable enough: is it guaranteed that my application template will always be accessible at that path ?
What if someone vendorize my application into their own project ? Does that even make sense for a command-line tool ?
Because of 2., I obviously can't/won't use go-bindata because I want to allow for the templates to be overriden if need be.
In summary: what is a good strategy to reliably refer to non-go, static files in a Go command-line tool ?
GOPATH is used for building the application. While you could look for GOPATH and check relative locations to each GOPATH entry at runtime, you can't be sure it will exist (unless of course you make it a prerequisite for running your application).
go get itself is a convenience for developers to fetch and build a go package. It relies on having a GOPATH (though there's a default now in go1.8), and GOBIN in your PATH. Many programs require extra steps not covered by the simple go tool, and have scripts or Makefiles to do the build. If you're targeting users that aren't developers, you need to provide a way to install into standard system paths anyway.
Do what any regular program would do, and use some well-known path to locate the template files. You can certainly add some logic in your program to check for a hierarchy of locations: relative to $GOPATH, relative to the binary, working directory, $HOME, etc; just provide a list of locations to the user that your program will look for templates.
If i've built a web app using code igniter, what's the proper way to deploy it? Should my install only include my files, or do I also package all the codeigniter code with it?
I'm just entering into the world of open source so I'm not so sure what protocol is.
Thanks.
This is a good question and I've seen it done both ways. There's definitely reasons Not to include the CI files. Like any potential in the future license changes. And it seems like with the projects that are shared by more experienced developers that is how they do it.
Because if you are sharing your project for other CI developers, then the reality is they will not use the copy of CI you include - they will fold your files into their version of CI. So including JUST the files needed for your app - actually makes much it easier. Its certainly what I would prefer. Just keep the standard application folder structure: config controllers models etc. but only include the folders that you have files for. And make it clear what version of CI you have tested it on. If you can say it will work on the release version (not the beta) then people on PHP 5.2 will know they can use it.
Of course you need to include all the CodeIgniter files, or else how would it run?
Most people tend to rename the application and system files and place them outside of the web root for security reasons. "After moving them, open your main index.php file and set the $system_folder and $application_folder variables, preferably with a full path, e.g. '/www/MyUser/system'".
Is it a best practice to commit a .sln file to source control? When is it appropriate or inappropriate to do so?
Update
There were several good points made in the answers. Thanks for the responses!
I think it's clear from the other answers that solution files are useful and should be committed, even if they're not used for official builds. They're handy to have for anyone using Visual Studio features like Go To Definition/Declaration.
By default, they don't contain absolute paths or any other machine-specific artifacts. (Unfortunately, some add-in tools don't properly maintain this property, for instance, AMD CodeAnalyst.) If you're careful to use relative paths in your project files (both C++ and C#), they'll be machine-independent too.
Probably the more useful question is: what files should you exclude? Here's the content of my .gitignore file for my VS 2008 projects:
*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/
(The last entry is just for the AMD CodeAnalyst profiler.)
For VS 2010, you should also exclude the following:
ipch/
*.sdf
*.opensdf
Yes -- I think it's always appropriate. User specific settings are in other files.
Yes you should do this. A solution file contains only information about the overall structure of your solution. The information is global to the solution and is likely common to all developers in your project.
It doesn't contain any user specific settings.
You should definitely have it. Beside the reasons other people mentioned, it's needed to make one step build of the whole projects possible.
I generally agree that solution files should be checked in, however, at the company I work for we have done something different. We have a fairly large repository and developers work on different parts of the system from time to time. To support the way we work we would either have one big solution file or several smaller. Both of these have a few shortcomings and require manual work on the developers part. To avoid this, we have made a plug-in that handles all that.
The plug-in let each developer check out a subset of the source tree to work on simply by selecting the relevant projects from the repository. The plugin then generates a solution file and modifies project files on the fly for the given solution. It also handles references. In other words, all the developer has to do is to select the appropriate projects and then the necessary files are generated/modified. This also allows us to customize various other settings to ensure company standards.
Additionally we use the plug-in to support various check-in policies, which generally prevents users from submitting faulty/non-compliant code to the repository.
Yes, things you should commit are:
solution (*.sln),
project files,
all source files,
app config files
build scripts
Things you should not commit are:
solution user options (.suo) files,
build generated files (e.g. using a build script) [Edit:] - only if all necessary build scripts and tools are available under version control (to ensure builds are authentic in cvs history)
Regarding other automatically generated files, there is a separate thread.
Yes, it should be part of the source control.
When ever you add/remove projects from your application, .sln would get updated and it would be good to have it under source control. It would allow you to pull out your application code 2 versions back and directly do a build (if at all required).
Yes, you always want to include the .sln file, it includes the links to all the projects that are in the solution.
Under most circumstances, it's a good idea to commit .sln files to source control.
If your .sln files are generated by another tool (such as CMake) then it's probably inappropriate to put them into source control.
We do because it keeps everything in sync. All the necessary projects are located together, and no one has to worry about missing one. Our build server (Ant Hill Pro) also uses the sln to figure which projects to build for a release.
We usually put all of our solutions files in a solutions directory. This way we separate the solution from the code a little bit, and it's easier to pick out the project I need to work on.
The only case where you would even considder not storing it in source control would be if you had a large solution with many projects which was in source control, and you wanted to create a small solution with some of the projects from the main solution for some private transient requirement.
Yes - Everything used to generate your product should be in source control.
We keep or solution files in TFS Version Control. But since or main solution is really large, most developers have a personal solution containing only what they need. The main solution file is mostly used by the build server.
.slns are the only thing we haven't had problems with in tfs!