Opened 8 years ago

Closed 7 years ago

#14731 closed enhancement (worksforme)

build command line parameter order matters when configuring basePath

Reported by: tommahieu Owned by: Rawld Gill
Priority: undecided Milestone: 1.8
Component: BuildSystem Version: 1.7.1
Keywords: Cc:
Blocked By: Blocking:

Description

Apparently the order by which command line parameters are passed to the new build system is important. if I do a custom build with (test files are attached in tarball, dojo 1.7.1 is supposed to sit in the js directory):

./build.sh -p ../../firstsample/firstsample.profile.js --require ../../firstsample/run.js

then the build system does not discover my packages:

processing profile resource /home/tomm/IdeaProjects/Proj/sample/Test/js/firstsample/firstsample.profile.js
processing require resource /home/tomm/IdeaProjects/Proj/sample/Test/js/firstsample/run.js
warn(209) Missing or empty package.json. filename: /home/tomm/IdeaProjects/Proj/sample/Test/js/firstsample/js/dojox/package.json
warn(209) Missing or empty package.json. filename: /home/tomm/IdeaProjects/Proj/sample/Test/js/firstsample/js/firstsample/package.json
warn(209) Missing or empty package.json. filename: /home/tomm/IdeaProjects/Proj/sample/Test/js/firstsample/js/dijit/package.json
warn(209) Missing or empty package.json. filename: /home/tomm/IdeaProjects/Proj/sample/Test/js/firstsample/js/dojo/package.json

...

if I run the command with the --require parameter first, followed by the profile --parameter, everything works fine:

$./build.sh --require ../../firstsample/run.js -p ../../firstsample/firstsample.profile.js
processing require resource /home/tomm/IdeaProjects/Proj/sample/Test/js/firstsample/run.js
processing profile resource /home/tomm/IdeaProjects/Proj/sample/Test/js/firstsample/firstsample.profile.js
info(107) Package Version: package: dojox; version: 1.7.1
processing profile resource /home/tomm/IdeaProjects/Proj/sample/Test/js/dojox/dojox.profile.js
processing profile resource /home/tomm/IdeaProjects/Proj/sample/Test/js/firstsample/firstsample.profile.js
info(107) Package Version: package: dijit; version: 1.7.1
processing profile resource /home/tomm/IdeaProjects/Proj/sample/Test/js/dijit/dijit.profile.js
info(107) Package Version: package: dojo; version: 1.7.1
processing profile resource /home/tomm/IdeaProjects/Proj/sample/Test/js/dojo/dojo.profile.js
discovering resources...

It appears that the basePath profile parameter is not interpreted in the first case (require after profile parameter)

It took me quite a while to figure this out as I kept thinking my profile and loader configuration combined with my file structure was wrong. In the end, I figured out thate the require and profile configuration files are parsed in the order in which they are given at the command line. The builder seems to look for a basePath parameter in both the loader configuration and the profile. If it doesn't find one, the builder uses the default basePath (location of the profile).

This appears to be a problem when the loader configuration (which normally does not hold a basePath paramater?) is parsed after the profile. The basePath was correct after the parsing of the profile, but forced to the default after the parsing of the loader configuration. Reversing the order of the parameters on the command line resolves the problem

When looking at the code in argv.js, the value is determined by the fixBasePath function, which indeed does not look beyond the scope of the file that is being parsed at that moment, last file in processVector wins.

I actually wondered why fixupBasePath is called in the case of "require" and "dojoConfig" scriptTypes. Is a basePath really meaningful at runtime when you already have baseUrl? Shouldn't basePath be limited to profiles only?

My suggestion: If a basePath does need to be allowed in dojoConfig and loader profiles, I think the parser should never override an explicitly defined basePath (which is what happens in the given example). Moreover, if basePaths are defined in multiple places, an exception should probably be thrown if they are conflicting.

I'd submit a patch, but I have no idea which solution is best :)

Attachments (1)

Test.tar.gz (1013 bytes) - added by tommahieu 8 years ago.
example used in the ticket description, dojo 1.7.1 is supposed to sit in the Test/js directory

Download all attachments as: .zip

Change History (5)

Changed 8 years ago by tommahieu

Attachment: Test.tar.gz added

example used in the ticket description, dojo 1.7.1 is supposed to sit in the Test/js directory

comment:1 Changed 8 years ago by Rawld Gill

Status: newassigned

comment:2 Changed 8 years ago by Rawld Gill

Milestone: tbd1.8

Hi tommahieu,

Thanks for your report. I have to digest it. In the meantime, have your seen:

http://dojotoolkit.org/reference-guide/build/buildSystem.html#build-buildsystem

Please read the section "Commandline Switches" at your convenience and see if it helps clarifies things.

comment:3 Changed 8 years ago by tommahieu

Hello rcgill,

Yes, I've read the documentation (albeit on livedocs :) ), and found in interesting that you can pass multiple configurations. The docs are also clear on precedence: "if two or more resources attempt to set the same profile property, then the last input wins".

Except, in my example, basePath is not set by loader configuration (--require argument), yet the builder still overrides it if I pass it after the profile (which does explicitly set a basePath). I suppose this only happens with the basePath configuration variable though, since it receives special attention by the build system.

comment:4 Changed 7 years ago by Rawld Gill

Resolution: worksforme
Status: assignedclosed

Hi tommahieu! Thanks for the great report.

The idea is to allow a loader config to double as a builder config (recall that the loader will simply ignore properties that are meaningless to the the loader). Therefore, a --require profile is treated essentially the same as a --profile profile...including derivation of the basePath if not given.

As it stands now the rule is pretty simple: load profiles left-to-right; last property value set wins. You could (and did) easily solve the problem by reordering...you could also add a --basePath command line switch which would override any profile switch.

Also note to help diagnose these kind of things, the first think I do is replace the -r command line switch with --check. This dumps out the complete, computed profile which helps drill down as to whether it's a profile problem or a builder problem.

Note: See TracTickets for help on using tickets.