Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#4565 closed defect (wontfix)

Consider allowing building from a release build

Reported by: James Burke Owned by: James Burke
Priority: high Milestone: 1.1
Component: BuildSystem Version: 0.9
Keywords: Cc: Adam Peller
Blocked By: Blocking:


Consider if we should allow the possibility for someone to take the 0.9 release, add in the util/buildscripts folder and have the build work. Today, it will probably not work.

I'm not sure this is a real use case: you should just be able to get the source zip file and do a build from there. IBM has a special requirement in this case, but I think we satisfy that today: they deliver the 0.9 source without the util/buildscripts folder. We have that folder available as a release output.

Also, I think this should probably be addressed via the web build tool: have the option to just generate a layer from there without needing to get the util/buildscripts folder at all.

So I'll likely close this bug as wontfix, but I'll keep it open for a little bit. Keep this bug around for historical purposes, so I remember the discussion around it.

Attachments (1)

buildFromBuild.patch (8.1 KB) - added by James Burke 14 years ago.
Partial patch taken from util/buildscripts dir. Not complete. See ticket for more info.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 15 years ago by Adam Peller

Cc: Adam Peller added

what's required to be able to just add the util/buildscripts and make it work?

comment:2 Changed 15 years ago by James Burke

If you have a source distribution without the util/buildscripts dir, then go to and download the buildscripts tar.gz or zip file, unpack it inside your source distribution.

I still need to link to this on the download page once I get around to improving it with more download info.

The buildscripts bundle is part of the release script, so it will be generated for any new releases too.

comment:3 Changed 15 years ago by James Burke

Resolution: wontfix
Status: newclosed

comment:4 Changed 15 years ago by James Burke

Milestone: 1.01.1
Resolution: wontfix
Status: closedreopened

Reopening, after talking more with Alex. We'll try a solution where the build process delivers the "source" dojo.js in the built _base dir (as dojo.src.js or something like that). Then change the build process to look for that file first, then default to the parent dojo.js if it cannot be found. That should get us to this point.

comment:5 Changed 14 years ago by James Burke

Resolution: wontfix
Status: reopenedclosed

Closing this as wontfix. After doing the change for #4906, it is a little tricky dealing with running the build over a directory that has already been through a build. Namely, dealing with other layers in the build, not just dojo.js.

For instance, dijit/dijit.js and dijit/dijit-all.js: in those cases we do not have the original layer source (just a bunch of dojo.require() calls), just a file with a lot of inlined modules. So this makes it hard to know how to rebuild that file, particularly if the user changed one of the modules included by that file.

I really do not want to keep track of "original layer file source" in some directory for each build. Particularly since it depends on the build profile, something that may not be available the second time the build is run on the directory.

So this is way more tracking and complication than what I want the build system to do. The build system is already tricky enough without these changes. The buildLayers functionality for #4906 was bad enough.

Changed 14 years ago by James Burke

Attachment: buildFromBuild.patch added

Partial patch taken from util/buildscripts dir. Not complete. See ticket for more info.

comment:6 Changed 14 years ago by James Burke

I just attached a partial patch for this (buildFromBuild.patch). However the patch is not complete: I stopped once I was going to have to modify the buildUtil.js files for buildUtil.loadDependencyList and related functions to load files like dojo.js and _loader/loader.js from the release dir and not the "source" dir. This will have an impact on the ability to do web builds effectively -- I have to put in more config/switches.

This patch is getting more complicated, and I do not want to support it. Allowing this capability doubles any testing effort for any new build feature that is added, and it makes the code even more unmaintainable.

So I'm going to stop looking at this even though I talked with Alex at DDD:IV about looking into it.

Note: See TracTickets for help on using tickets.