Why are the build directories so big?

[Rob Willett]

We were looking at our project directories and wondered why they are so big. 

One app takes up 526MB which is rather a lot. Keeping ten copies is 5GB, we keep a lot more versions than that as well :)

Drilling down into the directory

macpro:Jambuster rwillett$ du -s -h *

4.0K Makefile

4.0K bower.json

4.0K build.json

8.0K config.xml

4.0K gulpfile.js

 44K hooks

4.0K ionic.project

 22M jambuster.apk

4.0K jambuster.london.keystore

100K jamcams.json

2.0M node_modules

4.0K package.json

8.0K paw

393M platforms

 61M plugins

4.0K plusgins_list

 14M res

1.1M resources

4.0K scss

 33M www

33MB for our code, OK, we can prune that down a bit, but 393MB in the platforms directory!

Drilling down to platforms

macpro:Jambuster rwillett$ cd platforms/

macpro:platforms rwillett$ du -s -h *

242M android

150M ios

4.0K platforms.json

242MB vs 150MB Android vs IOS. Quite a big difference. Our app is around 40MB in production. 

Heading down to android

du -s -h *

8.0K AndroidManifest.xml

1.8M CordovaLib

 28K android.json

 24M assets

196M build

 12K build.gradle

4.0K com.transistorsoft.cordova.background-geolocation

5.3M cordova

4.0K cordova-plugin-badge

 56K gradle

8.0K gradlew

3.3M libs

296K platform_www

4.0K project.properties

4.0K pushwoosh-cordova-plugin

3.5M res

4.0K settings.gradle

500K src

So its the build directory, mmm... lets take a look there

macpro:build rwillett$ du -s -h *

 96K generated

127M intermediates

 68M outputs

1.8M tmp

Lets check intermediates

macpro:intermediates rwillett$ du -s -h *

 48M assets

4.5M blame

  0B bundles

1.6M classes

  0B dependency-cache

 16K dex-cache

4.5M exploded-aar

812K incremental

8.0K incremental-safeguard

8.0K instant-run-support

6.5M jniLibs

 24K manifests

3.1M pre-dexed

 44M res

  0B rs

  0B shaders

280K sourceFolderJavaResources

 16K symbols

 13M transforms

So the assets directory is the big one

macpro:assets rwillett$ du -s -h *

 24M debug

 24M release

heading down to debug we find the www folder from waaaay up above.

So is there anything to trim these directories down at all? 

The reason we ask is that we often transfer stuff from our main machines to laptops, we tend to transfer the whole directory so we have everything to work with and moving 500MB around is a lot. As we move to multiple applications we will start to double and triple that.

Any suggestions welcomed.

Thanks

Rob 

[Kerri Shotts]

My suggestion would be to use Git (or similar) and exclude various directories from the repository, like "platforms/" and "plugins/". (My perspective is that they are build artifacts, and there's no benefit to copying them around everywhere.)

Also, if you use a bundler + npm to manage your JavaScript dependencies (or similar, like JSPM), you'll probably want to exclude node_modules as well, since these directories can get really large as well. If you must have exact versions when `npm install` is executed, specify the exact versions in package.json.

But yes, those intermediate files do chew up a lot of space. 

If you don't want to use a version system for this, you might just want to set up a script that you can use to copy your projects (minus unneeded directories).

[Rob Willett]

Kerri,

Long time no hear, Happy New Year from London.

We do use a version control system for all the user defined artefacts, TypeScript, CSS, HTML files. The problem we have is that we are now making a few different versions of our app, the central core and frameworks are the same and we have now got it down to 

1. A one line change in a TypeScript file defining the program behaviour.

2. A different set of icons, splash screens and other ephemeral items in $ROOT/res

3. A different config.xml with its own bundleId and other dedicated config items. 

We now have a master folder with each app sitting underneath it. There is a single master folder and a number of application folders in this root folder. All of the application folders have a mass of symbolic links pointing back to the master folder so that we only ever have one version of a file. The only things that aren't linked back are the build artefacts (sadly thats most of the 500MB) The build for each application is defined in a dedicated file (see point 1). We have individual config.xml and icon files as well. This means that all our applications are in lock sync with each other. We can also build IOS/Android versions for each application automatically. Its taken a long time to get to this stage, indeed we exchanged emails about this in the middle of last year from memory. 

We have also written a large number of scripts that check the sanity of each app, e.g. checks bundle Ids, icons, links and where they point to to make sure we build and test the right sodding application at the right time. :)

So we are now at the stage of having a decent automated multi-app build system, it's just that each app is 500MB and so moving this around is getting a little unwieldy. We will be adding 2-3 more apps over the year so our build directory will be around 2.5 to 3GB. I suspect this is one of these first world problems that we will just have to grin and bear it.

All the best

Rob

--
-- You received this message because you are subscribed to the Google
Groups "phonegap" group.
To post to this group, send email to phon...@googlegroups.com
To unsubscribe from this group, send email to
phonegap+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/phonegap?hl=en?hl=en
 
For more info on PhoneGap or to download the code go to www.phonegap.com
---
You received this message because you are subscribed to the Google Groups "phonegap" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phonegap+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.