Create a new output file for the result of autogen
rhempel opened this issue · 15 comments
I think it would be a good idea to have autogen
not overwrite the input file so that it's easier to figure out what's hand-written and what is autogen
ed.
On the other hand, maybe an option to autogen
that strips out the autogen
ed code would work as well.
I am going to see if either method makes sense.
I chose to set it up as an in-place operation because I didn't want to have two copies of code files. I thought it would be weird if the files that one saw in the root of a repo were either:
- Skeletons without the major autogen bits or normal metadata files (because all the gen'd code, build scripts, etc were in a subfolder)
- Seemingly normal, even though the files in the root of the repo wouldn't actually change the library because they'd be overwritten
If you think that there are better ways of doing it, feel free to try it out; I'd be happy to discuss.
I feel the same way about having two copies of essentially the same content. Maybe the better choice is an option to autogen
that strips the autogen
ed code out would be better. The reason I would like to have just the skeleton is to show just how much autogen
actually does for us - once you get the base device class done, and have a liquid
template to generate the repetetive stuff, the rest is pretty easy!
It should be easy to wrap this into a script. Stripping the code should not be needed often, so that could work for occasional inspection.
It should be pretty easy to add a flag to empty autogen-ed content, although at the moment I don't have a command-line parser in place in that script; I just split the command-line content by space and assume they are autogen groups. I'll have to implement something better...
I think rather than add complexity to the autogen
script, we can use @ddemidov's idea - which I finally figured out after a bit of head scratching :-) It's not needed very often at all.
We'll still put only the latest autogen
ed binding into the repo - we don't want users to have to do anything special to start using the binding
@WasabiFan - I read about different command line parsing libs for node
- there's a lot to choose from. Could I ask you to pick a library for basic command line parsing, and I'll add support for the -x
flag that parses the file and outputs nothing in the autogen
ed blocks.
I don't program with node
everyday so I don't know the command line parser all the cool kids are using :-)
It's more elegant than monkeying around with linking to blank templates.
Sure; I'll look through the options and implement something. Give me a day to find some free time and I'd be happy to check it out.
Good morning,
@WasabiFan "Commander" looks fine to add command-line features.
https://www.npmjs.com/package/commander
If you need some help, I could help you, I work in the day with Node.js
Cheers
I was looking at commander
- the pirate themed parser yargs has a certain appeal as well - and it's under active development.
I should be able to figure it out, thks. It's a low priority task.
yargs is a great choice. I replaced commander in some project by yargs (if I recall right because yargs had support for boolean args).
@rhempel Pull and check out my changes -- I added calls to yargs (which is the library I've used in the past) and included a flag to clear the templated sections. That flag can either be -x
or --clear
.
I haven't added the config to tell yargs to offer command help with useful messages yet.
P.S. This is the first time I have pulled on this machine since we switched the python submodule. When I run git submodule update
, it complains with errors like this:
> git submodule update
fatal: reference is not a tree: 91bfa71551d8a9f6649705fda68de904254ef745
Unable to checkout '91bfa71551d8a9f6649705fda68de904254ef745' in submodule path 'python'
Usually, I'd take that as a sign that someone hadn't pushed their commits -- but that commit is clearly there on GitHub. Any ideas?
git submodule update --init
?
you might have to manually update the submodule under your .git
directory to point to the new repository.
I also need to update the official ev3dev-lang
to point at the right commit in my repo
@rhempel Did we get this resolved with the additional command?
you might have to manually update the submodule under your .git directory to point to the new repository.
@dlech In the end I just accepted that it was out of my realm and resorted to standard tactics.