Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(970)

Issue 343030043: More flexible create-module.py and contrib/wscript

Can't Edit
Can't Publish+Mail
Start Review
Created:
3 months, 3 weeks ago by Peter Barnes
Modified:
5 days, 2 hours ago
Reviewers:
Tom Henderson
CC:
ns-3-reviews_googlegroups.com
Visibility:
Public.

Description

Consider a project in contrib which wants this structure pulled from a single repo: contrib/ wscript project/ .repo // could be .git or .hg, for example main/ wscript // builds executable 'project' from main.cc and other.cc main.cc other.cc modules/ moduleA/ // Contains normal module structure wscript model/ ... moduleB/ // Contains normal module structure data/ // No source code here, so no wscript One can't do this at the moment for two reasons: * contrib/wscript won't recognize the project directory because the top level does not contain a wscript file * Each "normal" module directory has to be created by hand, or created in src, then moved to its final location. This patch provides two enhancements to enable this kind of project: 1. Enable the create-module.py script to create modules in the contrib directory, as well as the src directory. 2. Enable modules in the contrib directory to have arbitrary structure. To accomplish these goals the patch modifies a couple of heuristics: * create-module.py accepts arbitrary paths, using the last path element as the name of the module (but see the question below). * contrib/wscript walks the directory tree, looking for directories containing wscript files. When found, add that directory to the list of contrib modules to process. It is not an error for a tree under contrib not to contain any wscript files; this tree is simply ignored. (The data directory above is an example.) Since create-module.py is more general, this patch moves it to the utils directory. Question: Should we restrict to just module paths matching src/new-module and contrib/new-module? The first restriction might be useful. The second conflicts with allowing contrib modules to have arbitrary structure.

Patch Set 1 #

Patch Set 2 : Revised patch #

Unified diffs Side-by-side diffs Delta from patch set Stats (+60 lines, -19 lines) Patch
M contrib/wscript View 1 4 chunks +33 lines, -9 lines 0 comments Download
M doc/manual/source/documentation.rst View 1 chunk +1 line, -1 line 0 comments Download
M doc/manual/source/how-to-write-tests.rst View 1 chunk +1 line, -1 line 0 comments Download
M doc/manual/source/new-modules.rst View 1 1 chunk +11 lines, -4 lines 0 comments Download
M utils/create-module.py View 1 2 chunks +14 lines, -4 lines 0 comments Download

Messages

Total messages: 7
Tom Henderson
(this is mainly an initial comment to check whether it will post to ns-3-reviews; initial ...
3 months, 3 weeks ago (2018-04-25 17:22:55 UTC) #1
Peter Barnes
On 2018/04/25 17:22:55, Tom Henderson wrote: > Is there a need perhaps to have both ...
3 months, 3 weeks ago (2018-04-25 17:34:43 UTC) #2
Tom Henderson
On 2018/04/25 17:34:43, Peter Barnes wrote: > On 2018/04/25 17:22:55, Tom Henderson wrote: > > ...
3 months, 3 weeks ago (2018-04-25 17:42:43 UTC) #3
Peter Barnes
Fixed test issue in listing available test.
2 months, 3 weeks ago (2018-05-24 20:09:41 UTC) #4
Peter Barnes
@Tom: I don't understand your last comment re: project grouping and project structure... Are there ...
1 week, 4 days ago (2018-08-06 23:13:49 UTC) #5
Tom Henderson
On 2018/08/06 23:13:49, Peter Barnes wrote: > @Tom: I don't understand your last comment re: ...
5 days, 20 hours ago (2018-08-12 22:48:11 UTC) #6
Peter Barnes
5 days, 2 hours ago (2018-08-13 17:12:47 UTC) #7
On 2018/08/12 22:48:11, Tom Henderson wrote:
> 
> utils/create-project.py contrib/projectname moduleNameA moduleNameB
moduleNameC
> 
> would yield
> 
> contrib/
>         projectname/
>                     moduleNameA
>                     moduleNameB
>                     moduleNameC
> 
> and do not continue with the standalone 'create-module.py'

Ahh, now I get it.  An alternative to supporting create-project.py *and*
create-module.py might be:

utils/create-module.py --project projectname moduleA moduleB moduleC

One script to rule them all.

Do projects only make sense in contrib (as I've implicitly assumed in the
command above)?  Or should we the script be agnostic?
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b