Opened 10 years ago

Closed 10 years ago

#15849 closed defect (invalid)

Should the build system support nested module paths in the 'packages' array?

Reported by: Nick Fenwick Owned by: Rawld Gill
Priority: undecided Milestone: tbd
Component: BuildSystem Version: 1.8.0
Keywords: Cc:
Blocked By: Blocking:


I've been using this system for years, it broke with recent changes for 1.8.

Will attach test .tgz, contains:

  • buildroot/build.profile.js - example build profile that wants to build master/child2
  • buildroot/dojo-release-1.8.0-src/master - example modules directory, contains master/child2

You can run the build with:

  • extract dojo into dojo-release-1.8.0-src
  • cd dojo-release-1.8.0-src/util/buildscripts
  • ./ -r -p ../../../build

The issue is with the packages declaration in build.profile.js:


The idea is that I have several modules under 'master' that I want to conditionally build, controlled by the build profile, e.g.

customer1.profile.js - builds master/child1
customer2.profile.js - builds master/child2
customer3.profile.js - builds master/child3

Unfortunately, this builds with the following error:

starting parsing resource...
error(324) Error while transforming resource. resource: /home/neek/workspace/buildroot/master/child2/Foo.js; transform: 0; error: Error: ENOENT, open '/home/neek/workspace/buildroot/master/child2/Foo.js'

You can see it has chopped a directory level off .. instead of looking for ...buildroot/dojo-release-1.8.0-src/master... it's looking for ...buildroot/master... and encounters an io error ENOENT.

The fix so far has been to change the build profile to always have:


This builds all modules under master (master/child1, master/child2 etc) and then a post-build step has to manually delete the ones we don't want for each build. The child modules are 1-2Mb in size and take considerable time to build so this is far from optimal.

Should the builder support this behaviour? ..or will we be forced to reorganise our build to break each master/child<n> module into a top level module, or perhaps a pre-build step that arranges for just one master/child<n> module to be in place when the build runs?

Attachments (1)

buildroot.tgz (550 bytes) - added by Nick Fenwick 10 years ago.
untars to a 'buildroot' directory containing sample build.

Download all attachments as: .zip

Change History (2)

Changed 10 years ago by Nick Fenwick

Attachment: buildroot.tgz added

untars to a 'buildroot' directory containing sample build.

comment:1 Changed 10 years ago by Rawld Gill

Resolution: invalid
Status: newclosed

This is a duplicate of #15897. I posted a full explanation there. The short answer is package names must be "The first segment of an absolute module ID prefix"; see the heading "packages" in

Note: See TracTickets for help on using tickets.