Background
We have scripts that generate a large portion of our code.
We don't want to use scripts for generating all of the code.
Typically, we would keep this code separate, but we are considering scripts that generate portions of the code that will also be modified by programmers, e.g. function / class definitions, i.e. first we parse a header file that specifies the function parameters and enumerations, then we generate all the empty functions.
We can ensure that programmers will never modify code that is generated by the scripts.
We need a method to automate the merging of these files after being edited by the scripts; e.g. our input definition file is updated (externally) and we need to modify the function parameters.
Method
Two scripts: "Previous" and "Current" (identical)
Modify "Current" and regenerate code; "P4 edit" into changelist
Merge code:
2.a. Base = Generated code from "Previous"; in temporary folder
2.b. Left = Generated code from "Current"
2.c. Right = Existing code; current version checked into P4
Save "Current" as "Previous"
Problem
I can't figure out how to automate step #2. We have over 100 files we'd like to auto generate so manually merging is not an option.
Using "p4merge.exe" requires GUI interaction; as far as I can tell.
I looked at "p4 merge", "p4 integrate", "p4 resolve" and "p4 sync", but I couldn't figure out how to invoke the correct behavior.
Any help would be appreciated, including alternative methods.
Cheers.
Per jamesdlin's comments, I figured out how to accomplish what I wanted.
New Method
One script "Current".
Add generated files to P4 (always version #1)
"p4 sync [file]#1" then "p4 edit [file]"
Modify "Current" and regenerate code
Run "p4 sync" again (without revisions) to mark the files for resolve.
Run "p4 resolve -am" to auto resolve the files.
This should work even after multiple iterations of the script. As long as I can avoid conflicts then this should be completely automated.
Rather than combining your machine-generated code in the same source files as the human-authored code, what about changing your code generation strategy so that your tool generates the super-class code, and humans can individually author sub-classes of the machine-generated classes which override the necessary methods to provide the needed behavior.
That's how I've typically done this sort of development in the past.
Related
Does MATLAB have the following capability: take source code that directly includes other .m files and output the source that would result from merging all included files?
For example, consider script_one.m:
% some matlab code
script_two
% more matlab code
I would like to programmatically generate the .m file that would result from copying and pasting the contents of script_two.m into script_one.m. This is difficult to do with normal scripting tools because I would essentially need a MATLAB symbol table to determine which identifiers correspond to sourceable scripts. I highly doubt that Matlab provides such a facility, but am open to other ideas.
The "use case" is the need to modify the source (using sed) but the changes need to propagated to any dependent scripts, such as script_two.m. As I don't have a listing of the dependent scripts, they can only be identified by going through the source manually (and it needs to be done on a large number of dynamically created files).
Some details on the use case:
The main script (script_one) is called with dynamically created header files, e.g., matlab [args] -r 'some definitions; script_two; script_three; others; main_script();quit()'. This is run on machine A; for load balancing, it may need to be run instead on machines B, C, etc, which mount the file system of A at some point. Any paths in the included .m files (which are mainly used as headers) would need to be essentially chrooted to work on the new host. The simplest solution would be to preprocess the code which was generated for machine A, using sed to replace all paths for the new host (B, C, etc.). It can of course be solved by making the changes in matlab, but a sed one-liner is a more attractive solution in terms of parsimony.
In general, no, it's not possible in MATLAB. What you want is a language feature common to languages that require compilation step before execution, but this is not MATLAB's language model, and therefore, it is only doable via hacky wacky language abuse.
You could, conceivably, create a master script, which takes care of coordinating the generation of new source files, and executing them via eval():
[o,e] = system('<your sed command here, to generate script_one.m>');
% ... some more code
% execute newly generated M-file
[outputs] = eval('script_one');
But I hope you see and agree that this turns into spaghetti really quickly.
Executing a script with changing contexts and parameters is exactly what the function language feature was invented for :)
I'm trying to configure the P4Eclipse plugin (2014.1.965331) to use Beyond Compare as external Merge tool.
I have configured the Bcomp.exe as Perforce Merge in Perferences -> Team -> Perforce ->External Tools. so right now when resolve is requested it's opens the Beyond compare, but without the content of the files.
I know there is a list of arguments that needed to be passed (in P4V it's passed in the argument line as %1 %2 %b %r), as documented here : Using Beyond Compare with Version Control Systems
But no luck with the arguments, the trick for adding the arguments is to create a .bat file that calles to Bcomp.exe with additional arguments and set external merge toll to run the .bat file.
Is there any chance to configure it to work fine with beyond compare. (for now only 2 way merge is requested)
The list of arguments is fixed in the P4Eclipse code.
You're right, you're going to have to write a .bat/.cmd to adjust the parameter list.
P4Eclipse code is in our workshop.
The class that runs the command:
https://swarm.workshop.perforce.com/projects/perforce-software-p4eclipse/files/2014-1/src/3.7/plugins/com.perforce.team.ui/src/com/perforce/team/ui/p4merge/MergeRunner.java
Note method getBuilder() that makes the argument list. The constructor too. That's what we've got for documentation right now.
What it passes to the constructor depends on what you're doing - like merge vs diff.
For example, see the "new MergeRunner(...)" in
https://swarm.workshop.perforce.com/projects/perforce-software-p4eclipse/files/2014-1/src/3.7/plugins/com.perforce.team.ui/src/com/perforce/team/ui/p4merge/P4MergeResolveAction.java
We are using Mercurial as an SCM to handle the source script files of a program. Each project we manage has ~5000 files with each file containing a section with some product-specific informations about the file itself (version list, date, time etc.). This section is - due to the way it is structured - in 80% of the merges, the only section that has conflicts. They are easily resolved, but when merging around 300 files, it gets tiresome.
The problem is: I have no control over the way this section is written and I cannot change the format of the section itself, as it would make the file unusable by the program.
My question: is there a way in mercurial (hooks?), that allows me to
pre-process the file with a script
let mercurial do the merge
if merged correctly: post-process the file with a script. otherwise: "resolve-conflicts" as usual.
You could probably get away with it by creating a custom merge tool:
https://www.mercurial-scm.org/wiki/MergeToolConfiguration
A simple script that invokes 'diff' after removing the ever changing sections might be enough.
It sounds like those sections are the sort of nonsense that the (disrecommended) KeywordsExtension are built to handle, but I gather you don't have a lot of flexibility around them.
I am doing a refactoring of my C++ project containing many source files.
The current refactoring step includes joining two files (say, x.cpp and y.cpp) into a bigger one (say, xy.cpp) with some code being thrown out, and some more code added to it.
I would like to tell my version control system (Perforce, in my case) that the resulting file is based on two previous files, so in future, when i look at the revision history of xy.cpp, i also see all the changes ever done to x.cpp and y.cpp.
Perforce supports renaming files, so if y.cpp didn't exist i would know exactly what to do. Perforce also supports merging, so if i had 2 different versions of xy.cpp it could create one version from it. From this, i figure out that joining two different files is possible (not sure about it); however, i searched through some documentation on Perforce and other source control systems and didn't find anything useful.
Is what i am trying to do possible at all?
Does it have a conventional name (searching the documentation on "merging" or "joining" was unsuccessful)?
You could try integrating with baseless merges (-i on the command line). If I understand the documentation correctly (and I've never used it myself), this will force the integration of two files. You would then need to resolve the integration however you choose, resulting in something close to the file you are envisioning.
After doing this, I assume the Perforce history would show the integration from the unrelated file in it's integration history, allowing you to track back to that file when desired.
I don't think it can be done in a classic VCS.
Those versioning systems come in two flavors (slide 50+ of Getting git by Scott Chacon):
delta-based history: you take one file, and record its delta. In this case, the unit being the file, you cannot associate its history with another file.
DAG-based history: you take one content and record its patches. In this case, the file itself can vary (it can be renamed/moved at will), and it can be the result of two other contents (so it is close of what you want)... but still within the history of one file (the contents coming from different branches of its DAG).
The easy part would be this:
p4 edit x.cpp y.cpp
p4 move x.cpp xy.cpp
p4 move y.cpp xy.cpp
Then the tricky part becomes resolving the move of y.cpp and doing your refactoring. But this will tell Perforce that the files are combined.
I'd like to partly automate creation of GNU-style ChangeLog entries when working with source code in version control. The add-changelog-entry-other-window works with one file at a time and you have to visit the file to use it.
What I'd like to see instead is to have some command that would take an output of diff -u -p (or have integration with VC modes so it could process svn diff etc) and to create all the skeleton entries at once.
For example, if svn status shows
D file1.c
M file2.c
A file3.c
the command would create
2009-09-05 My Name <my.email>
* file1.c: Removed.
* file2.c: WRITE YOUR CHANGES HERE
* file3.c: New.
Better yet, if it could parse the changed files in some languages to an extent so it could offer:
* file2.c (new_function): New function.
(deleted_function): Removed.
(changed_function): WRITE YOUR CHANGES HERE
I have found this feature in Emacs manual, but I don't see how I could apply it here.
Any suggestions? Thanks.
EDIT: One answer suggested vc-update-change-log. Unfortunately it only supports CVS and it creates ChangeLog entries by querying the already-commited VC logs. Thus even if it supported svn and others, it would be impossible to commit the changes and the ChangeLog in the same commit.
EDIT2: Apparently add-changelog-entry-other-window (C-x 4 a) works not only from visited file but from diff hunk involving that file too. (Source) This is almost what I am looking for. This together with elisp loop to iterate through all hunks should solve it.
There is a function vc-update-change-log that automatically generates change log entries from the version control log entries.
diff-add-change-log-entries-other-window is documented to do exactly what you mentioned in EDIT2:
diff-add-change-log-entries-other-window is an interactive compiled
Lisp function in `diff-mode.el'.
(diff-add-change-log-entries-other-window)
Iterate through the current diff and create ChangeLog entries.
I.e. like `add-change-log-entry-other-window' but applied to all hunks.
Unfortunately, it doesn't work very well for, say, new files: it doesn't even include the filenames of such files in the skeletal changelog entry.
You might have better luck with gcc's mklog script, which you can get from http://gcc.gnu.org/viewcvs/gcc/trunk/contrib/mklog.
I don't know of a function that does this, but it should be easy to implement. Basically, you want to
get the changed files
for each file, call add-change-log
"Find change log file, and add an entry for today and an item for this file.
Optional arg WHOAMI (interactive prefix) non-nil means prompt for user
name and email (stored in `add-log-full-name' and `add-log-mailing-address').
Second arg FILE-NAME is file name of the change log.
If nil, use the value of `change-log-default-name'.
Third arg OTHER-WINDOW non-nil means visit in other window.
Fourth arg NEW-ENTRY non-nil means always create a new entry at the front;
never append to an existing entry. Option `add-log-keep-changes-together'
otherwise affects whether a new entry is created.
Option `add-log-always-start-new-record' non-nil means always create a
new record, even when the last record was made on the same date and by
the same person.
The change log file can start with a copyright notice and a copying
permission notice. The first blank line indicates the end of these
notices.
Today's date is calculated according to `add-log-time-zone-rule' if
non-nil, otherwise in local time."
so the magic code is going to look something like
(apply 'make-magic-change-log-entry changed-files-list)
and make-magic-change-log-entry simply curries the add-change-log function so that the only argument is file-name — you set the other ones.
I've written a function to do something similar to what you were talking about. You can get the code at http://www.emacswiki.org/emacs/log-edit-fill