To create distribution in perl I use Module::Build. And generate meta files by command: ./Build distmeta
Creating Makefile.PL
Creating README using Pod::Text
Creating LICENSE file
Created META.yml and META.json
At some point I decide to delete all autogenerated files. I run ./Build distclean
Cleaning up build files
Cleaning up configuration files
But metafiles are left: README, LICENSE
Is there a command to cleanup those files too?
The META files are removed because those are purely generated, but README and LICENSE are often customized, so they can't be safely removed or overwritten.
If you don't customize README and LICENSE, and if you insist on having a means of removing them, there is a solution if you use git. Don't add the files to the repository (which is made easy by adding them to .gitignore), and use git clean -dfx (instead of ./Build distclean) to freshen your directory.
Related
I wish to copy my existing Unity project into a new blank Unity project. It appears all the object references and many scripts are not configured properly/present in the Hierarchy in my scenes.
I only copied my assets folder/package.json into the new Unity project, because the rest of the files are dirty and have cached a lot of useless information.
Where are the files, detailing the scenes data located? I want to copy that over so I can run my scenes with all the object references, and scripts set onto the correct game objects.
Before starting always make Backups - you never know!
Cleaning Up / Migrating as a project folder
In general you will always need the Assets, ProjectSettings and the Packages folders (state Unity 2019 - relevant folders/files might change between versions)
All the rest you can delete and Unity will recreate/recompile them when you open the project again.
Also see Behind the Scenes (for newer Unity versions refer to Using external Version Control instead)
When backing up a project, or adding a project to a Version Control Repository, you should include the main Unity project folder, containing both the Assets
and ProjectSettings and Packages folders. All the information in these folders is crucial to the way Unity works.
As the names say
Assets are all your assets like scripts, images, prefabs etc. including alse the scenes.
ProjectSettings are all general settings for your project regarding things like quality, physics, player strings etc
Packages defines which packages shall be automatically imported by the PackageManager (manifest.json), which ones are dependencies, and which are even local packages (if any)
For me also some of the Library/*.asset files make sense to keep .. they store e.g. the build settings, target platform etc. so I don't have to configure them / switch platform from scratch every time I "reset". It's up to you of course if you want to do this as well.
You can also use any other version control system ... or of course also remove according folders and files manually but I always use GIT for my projects.
Also refer to Using external version control systems with Unity for some general information about the setup for version controlling your project(s).
So when I want to clean up a repository before coping it I usually use the following as *.gitignore (it is very basic - for a more complete and constantly updated version see the one on Github !).
Everything listed here can basically be deleted and will be re-compiled the next time you open the project in Unity. (Lines starting with ! are exceptions I added because as said for me it made sense to keep those as well.)
# This .gitignore file should be placed at the root of your Unity project directory
#
# Get latest from https://github.com/github/gitignore/blob/main/Unity.gitignore
#
/[Ll]ibrary/
/[Tt]emp/
/[Oo]bj/
/[Bb]uild/
/[Bb]uilds/
/[Ll]ogs/
/[Uu]ser[Ss]ettings/
# MemoryCaptures can get excessive in size.
# They also could contain extremely sensitive data
/[Mm]emoryCaptures/
# Recordings can get excessive in size
/[Rr]ecordings/
# Uncomment this line if you wish to ignore the asset store tools plugin
# /[Aa]ssets/AssetStoreTools*
# Autogenerated Jetbrains Rider plugin
/[Aa]ssets/Plugins/Editor/JetBrains*
# Visual Studio cache directory
.vs/
# Gradle cache directory
.gradle/
# Autogenerated VS/MD/Consulo solution and project files
ExportedObj/
.consulo/
*.csproj
*.unityproj
*.sln
*.suo
*.tmp
*.user
*.userprefs
*.pidb
*.booproj
*.svd
*.pdb
*.mdb
*.opendb
*.VC.db
# Unity3D generated meta files
*.pidb.meta
*.pdb.meta
*.mdb.meta
# Unity3D generated file on crash reports
sysinfo.txt
# Builds
*.apk
*.aab
*.unitypackage
*.app
# Crashlytics generated file
crashlytics-build.properties
# Packed Addressables
/[Aa]ssets/[Aa]ddressable[Aa]ssets[Dd]ata/*/*.bin*
# Temporary auto-generated Android Assets
/[Aa]ssets/[Ss]treamingAssets/aa.meta
/[Aa]ssets/[Ss]treamingAssets/aa/*
and as said for me personally it sometimes makes sense to add
# keep the *.asset files from Library
!/[Ll]ibrary/*.asset
If not done yet first initialize the repository running
cd your/project/root/path
git init
git add .gitignore *
this will show some warnings for every file that is listed in the .gitignore but you can ignore those warnings. It only says something similar like
You are trying to add an ignored file to the commit and it will be skipped
than run
git commit -m "Initial commit"
to make your first commit.
Now finally you can simply run git clean
git clean -xfd
which removes every file that is not tracked (so be sure to have always all files you want to keep at least staged (git add) or better commited first) or would be ignored by the *.gitignore.
-f
If the Git configuration variable clean.requireForce is not set to false, git clean will refuse to delete files or directories unless given -f, -n or -i. Git will refuse to delete directories with .git sub directory or file unless a second -f is given.
-d
Remove untracked directories in addition to untracked files. If an untracked directory is managed by a different Git repository, it is not removed by default. Use -f option twice if you really want to remove such a directory.
-x
Don’t use the standard ignore rules read from .gitignore (per directory) and $GIT_DIR/info/exclude, but do still use the ignore rules given with -e options. This allows removing all untracked files, including build products. This can be used (possibly in conjunction with git reset) to create a pristine working directory to test a clean build.
If unsure you can also add a
-n
Don’t actually remove anything, just show what would be done.
Note If you already had a .git repository but added / edited the .gitignore afterwards also refer to How to make Git "forget" about a file that was tracked but is now in .gitignore?
Migrating using UnityPackage
Another option for moving scenes or parts of the Assets between two different projects is using a UnityPackage. Note that this will not include any installed packages, settings etc but purely the assets and their asset-dependencies (linked prefab, materials, textures etc)!
From your current project export a UnityPackage
Excerpts from the Docs:
Use Export Package to create your own Custom Package.
Open the Project you want to export Assets from.
Choose Assets → Export Package from the menu to bring up the Exporting Package dialog box. (See Exporting Package dialog box image
below.)
In the dialog box, select the Assets you want to include in the package by clicking on the boxes so they are checked.
Leave the include dependencies box checked to auto-select any Assets used by the ones you have selected.
Click on Export to bring up the file explorer, and choose where you want to store your package file.
Name and save the package anywhere you like.
HINT: When exporting a package Unity can export all dependencies as
well. So, for example, if you select a Scene and export a package with
all dependencies, then Unity exports all Models, Textures and other
Assets that appear in the Scene as well. This can be a quick way of
exporting several Assets without manually locating them all.
alternatviely to step 2 you can also Right-Click on the Assets folder in the Project View and find the Export Package option in the context menu.
and then in the new project Import the UnityPackage
To import an Asset package:
Open the Project you want to import Assets into.
Choose Assets → Import Package → Custom Package.
In the file explorer, select the package you want and the Import Unity Package dialog box appears, with all the items in the package pre-checked, ready to install. (See Import Unity Package dialog box image below.)
Select Import and Unity puts the contents of the package into the Assets folder, which you can access from your Project view.
Alternatively to step 2 and 4 you can even simply drag and drop the unitypackage file into the Assets folder via the Unity Editor.
I wanted to do something similar which would apply to the "Move to Another PC" part.
I noticed that my projects are taking quite the amount of space and wanted to clean the proyect. I followed derHugo answer recommended "git clean" procedure but using his linked GitHub .gitignore file.
I had to make some changes so it work's on Unity 19.4:
# This .gitignore file should be placed at the root of your Unity project directory
#
# Modified from https://github.com/github/gitignore/blob/master/Unity.gitignore
#
# Keep Library Folder
#/[Ll]ibrary/
/[Ll]ibrary/Artifacts/
/[Ll]ibrary/ArtifactDB*
/[Ll]ibrary/PackageCache/
/[Tt]emp/
/[Oo]bj/
/[Bb]uild/
/[Bb]uilds/
/[Ll]ogs/
/[Uu]ser[Ss]ettings/
# MemoryCaptures can get excessive in size.
# They also could contain extremely sensitive data
/[Mm]emoryCaptures/
# Asset meta data should only be ignored when the corresponding asset is also ignored
!/[Aa]ssets/**/*.meta
# Uncomment this line if you wish to ignore the asset store tools plugin
# /[Aa]ssets/AssetStoreTools*
# Autogenerated Jetbrains Rider plugin
/[Aa]ssets/Plugins/Editor/JetBrains*
# Visual Studio cache directory
.vs/
# Gradle cache directory
.gradle/
# Autogenerated VS/MD/Consulo solution and project files
ExportedObj/
.consulo/
*.csproj
*.unityproj
*.sln
*.suo
*.tmp
*.user
*.userprefs
*.pidb
*.booproj
*.svd
*.pdb
*.mdb
*.opendb
*.VC.db
# Unity3D generated meta files
*.pidb.meta
*.pdb.meta
*.mdb.meta
# Unity3D generated file on crash reports
sysinfo.txt
# Builds
*.apk
*.aab
*.unitypackage
# Crashlytics generated file
crashlytics-build.properties
# Packed Addressables
/[Aa]ssets/[Aa]ddressable[Aa]ssets[Dd]ata/*/*.bin*
# Temporary auto-generated Android Assets
/[Aa]ssets/[Ss]treamingAssets/aa.meta
/[Aa]ssets/[Ss]treamingAssets/aa/*
Basically what I did was to not ignore the entire Library folder and only ignore the following:
/[Ll]ibrary/Artifacts/
/[Ll]ibrary/ArtifactDB*
/[Ll]ibrary/PackageCache/
Here's the procedure you should follow:
Backup your Project just in case.
Put the supplied .gitignore file on your project's root directory
Run the following commands:
# Initialize Repository
git init
# Add .gitignore file
git add .gitignore
# Add the rest of the files
git add *
# Commit changes
git commit -m "Initial Commit"
# Clean all untracked files and folders
git clean -Xfd
*Notice the -X option is capitalized on the git clean command, this avoids erasing any folder that's empty and untracked.
To verify everything is fine:
Load your Unity Project and check everything is still working correctly
Run git clean -Xfd once more to clean the project's files that were rebuilt by Unity.
Again, thanks derHugo for his detailed answer which was used to make this work on latest Unity releases.
When we do "yo webapp" (assuming webapp generator is installed), it scaffold projects which contains file relevant to bower, grunt and then there is app folder, which we all know what's it about.
My question is, out of this structure what are the files that needs to be maintained in SCM, Should it be only app directory or should it whole structure ?(assuming there are no additional grunt task or any build file changes from earlier scaffolding)
Yeoman webapp generator will produce a .gitignore file which includes files that should not be committed to a SCM. This file includes the following directories:
node_modules
dist
.tmp
.sass-cache
bower_components
test/bower_components
It is clear that .tmp and .sass-cache have no reason to be in the repo as they both are only temporary.
There is however a discussion whether bower (and rarely node) dependencies should be checked in. For most projects I recommend not to.
Please note that in either case one should never change the packages directly in the bower_components or node_modules folder as any change will be lost at next bower install or npm install. A fork of the original project (either as a independent repo or to folder in the project - e.g. lib) is a better idea - a follow up pull request would then add a lot of karma :)
The dist folder with the build of the application may be committed depending on your deployment method. There is a very good guide on deployment on Yeoman site.
As a start, you should put everything into SCM with the exception of app/bower_components, test/bower_components and node_modules. All files under these directories come from public repo, either node or bower repo.
In this setup, whenever another developer checkout from SCM, he needs to run 2 commands: npm install and bower install. What I typically do is I create a file called install.sh (install.bat on Windows) and have these 2 commands inside this script file. In this way, when you find that you need to run more commands for initialization, you can easily add to this script file and new developers can just checkout and run install.sh.
In some cases, I found that I need to perform small modification to a public library. In this case, I will check this library inside bower_components into SCM as well. This is not common, but it happens.
Every GitHub repo has the Download ZIP button, but is there a way to control what gets into the final zipball. For example we do not need and hidden files there, or even - unit tests.
Excerpt from Pro Git book:
You can tell Git not to export certain files or directories when
generating an archive. If there is a subdirectory or file that you
don’t want to include in your archive file but that you do want
checked into your project, you can determine those files via the
export-ignore attribute.
For example, say you have some test files in a test/ subdirectory, and
it doesn’t make sense to include them in the tarball export of your
project. You can add the following line to your Git attributes file:
test/ export-ignore
Now, when you run git archive to create a tarball of your project,
that directory won’t be included in the archive.
We recently moved from subversion to git, and then to Github, for several open source projects. Github was nice in that it provided a lot of functionality. One of the things I particularly like is the ability to download tags as zip or .tar.gz files.
Unfortunately Github recently discontinued downloads. That shouldn't be a problem because of the ability to download tags. However in the past we have not put a Makefile , configure script or any other autoconf-generated files into the repo because they get lots of conflicts when people merge.
What's the proper way to handle this?
Should I put autoconf and automake-generated files in the repo so people can download tags directly?
Or should there be a bootstrap.sh file and people are told to run that?
Or should I just do a make dist and put that into the repo?
Thanks
Publish the output of make dist via GitHub Releases
Your first option—putting the Autoconf- and Automake-generated files into the repository—is not a good idea. It's almost never beneficial to store generated files in source control. In this case, it's going to pollute your history with a lot of unnecessary and potentially conflicting commits, particularly if not all your contributors are using the same version of Autotools. Your third option—checking in the output of make dist—is a bad idea for exactly the same reasons as the first option.
Your second option—adding a "bootstrap" script that calls Autoconf and Automake to generate the configure scripts—is also a bad idea. This defeats the entire purpose of Autotools, which is to make your source portable across systems—including those for which Autotools is not available! (Consider what would happen if someone wanted to build and install your software on a machine on which they don't have root access, and where the GNU Build System is not installed. A bootstrap script is not going to help them because they'd first need to make a local installation of Autotools and possibly all its dependencies.)
The proper way of releasing code that uses Autotools is to produce a tarball with make dist (or better yet, make distcheck, since this will also run tests and do other sanity checks), and then publish this tarball somewhere other than the source repository.
Your original question, from April 2013, states that GitHub discontinued download pages. However, in July 2013, GitHub added a "Releases" feature that not only pre-packages your source tags, but also allows you to attach arbitrary files to each release. So on GitHub, the Releases page is where you should publish your make dist tarballs (and preferably also the detached GnuPG signatures of them).
Basic steps
When you are ready to make a release, tag it and push the tag to GitHub:
$ git tag 1.0 # Also use -s if desired
$ git push --tags
Use your Makefile to produce a tarball:
$ make dist # Alternatively, 'make distcheck'
Visit the GitHub page for your project and follow the "releases" link:
You will be taken to the Releases page for your project. The first time you visit, all you will see is a list of tags and automatically produced tarballs from the source tree:
Press the "Draft a new release" button.
You will then be presented with a form in which you should fill in the Git tag associated with the release and an optional title and description. Below this there is also a file selector labelled "Attach binaries by dropping them here or selecting them". Use this to upload the tarball you created in Step 2 (and maybe also a detached GnuPG signature of it).
When you're done, press the "Publish release" button.
Your project's Releases page will now display the release, including prominent download links for the attached files:
If you don't want to use GitHub Releases, then as pointed out in a previous answer, you should upload the tarballs somewhere else, such as your own website or FTP site. Add a link to this repository from your project's README.md so that users can find it.
The second is better: you want any user of your repo to be up and running as fast as possible, re-generating what he/she needs in order to build your program.
Since Git is very much a version control for text (as opposed to an artifact repo like Nexus), providing a way to generate the final binary is the way to go.
When you cut a release, upload the result of make distcheck to your project's download page: it's a makefile target that builds the tarball and verifies that it installs, uninstalls, passes tests and other sanity checks. Github being wrong-headed isn't an excuse: create a tree like this in your repo:
/
/source
/source/configure.ac
/source/Makefile.am
/source/...
/releases
/releases/foo-0.1.tar.gz
/releases/...
For developers, you should not have generated files in source control. Many modern autotooled projects bootstrap fine off an invocation of autoreconf -i.
i understand that nuget's package restore downloads and 'installs' the various required packages before building a project. but i can't work out what purpose this actually serves.
as far as i can tell, the 'installation' of a package during the package restore, isn't the same as a package's actual installation - for example, if you do the following:
install the jQuery package (NOTE that this adds jQuery script files to your project's 'Scripts' directory)
delete the added jQuery script files
delete the 'packages' directory (steps 2 & 3 simulate the state on a build machine, or other dev's machine)
do a build (triggering a package restore)
at this point the build states
2> Successfully installed 'jQuery 1.9.1'.
however, the jQuery package's script files are NOT added to the 'Scripts' folder, and the files are NOT added to the project.
this means that you have to check these files into source control anyway.
which also means that when you update this package, you have to manage adding/removing the new/old files (since different, versioned filenames are used). otherwise your 'Scripts' folder fills up with an endless history of versioned script files.
so, if you have to check everything in anyway, and you have to manually manage adding and removing files when updating, what exactly is the benefit of restoring the package on build? what purpose does this serve?
more to the point, why doesn't this serve the obvious purpose: automatically adding the package's files to the project?
Using NuGet Without Committing Packages to Source Control discusses the reason behind package restore.
Package restore means you do not have to check the packages folder into source control. Once enabled for your project it will download the packages and put them back into the packages folder at build time if they are missing. It will not, as you have found, add any package files to your project. In the case of jQuery all the files from the NuGet package are added to your project. Other NuGet packages however include one or more binary files.