Hi Charles,
I believe the risk to be low if we consider generating both the existing Makefile and the additional CMake support.
Ernesto identified test areas that require attention. I'll patch the change for testing, and also verify that both Makefile generation modes can peacefully coexist.
Regarding support for Windows, the modeled binary can be built via the CLI and also from within Visual Studio (tested 2013 and 2015.) And this includes the ability to step into the RTS library (which was my initial motivation for the comprehensive build.) So effectively, a modeled project can be built and debugged from within Eclipse using the Cygwin configuration and/or from within Visual Studio. Both Eclipse and VS can be supported concurrently for a given CDT project providing each has its own "build" artifact directory
- Bill
>>> "charles+zeligsoft.com" <charles@xxxxxxxxxxxxx> 5/16/2016 1:45 PM >>>
Hi William,
The MVP for v1.0 only has Linux as a platform/target.
Before this is brought into v1.0, could you please indicate the level of risk and potential impact this additional feature will have on a June 30 release?
Thanks!
Sincerely,
Thanks, Ernesto.
It would be good to make the freeze especially for 1.0.
Barry, the RTS changes strictly concern building on the various platforms/targets utilizing the HAVE_/NEED_ autoconf semantics. Tested environments thus far: Ubuntu 12.04, Fedora 20, VS 2013, VS 2015, cygwin, msys
Hi William. I reviewed your change, and it looks very good, but I have a couple of comments and questions, which I posted in Gerrit.
I also added Barry as a reviewer, since the Gerrit includes some changes in the RTS (Barry is responsible for the RTS).
We have a feature freeze on Friday for 1.0, so I'm not sure if it will make it in time, but hopefully it will.
Thanks!
PDF guides attached for both Windows and Ubuntu.
>>> "William Byrne" <williamb@xxxxxxxxxx> 5/14/2016 7:51 PM >>>
>> I'll speak to these details in the "simple" guide.
Attached PDF guide: Steps to setup and debug generated Papyrus-RT models on Windows using CMake & Cygwin
>>> "William Byrne" <williamb@xxxxxxxxxx> 5/14/2016 12:51 AM >>>
Hi Ernesto,
I rolled-back the formatting clean-up into the original commit via Amend (which is very convenient.) You may notice a few whitespace changes that amount to nothing more than converting tabs to spaces, and the elimination of trailing whitespace that Gerrit flagged in terrorizing red blocks.
I'll follow up with a simple step-by-step guide (with pics) for execution on Windows using Cygwin within Eclipse. But if you're familiar with cmake, give it a go. It should just work*. Aside from creating the canonical build sub-directory, be sure to symlink the RTS relative to the model source; e.g.,
[PingPong_CDTProject]/src/umlrt.rts -> org.eclipse.papyrus-rt/plugins/umlrt/runtime/rts
I'll speak to these details in the "simple" guide.
- Bill
* To generate CMakeLists.txt, the cmakeGen member in CppCodePattern must be set to true since generation defaults to the earlier Makefile implementation.
Tested x86 on: Ubuntu 12.04, Fedora 20, VS 2013, VS 2015, cygwin, msys
A couple of points regarding the code changes:
1) The new class, ConditionalDirective, might be refactored as a subclass of BlockInitializer, but for the time-being, the two classes are siblings that share an extracted subset of functionality encapsulated in the new ExpressionList class. The ConditionalDirective class provides #ifdef, etc.
2) The Makefile generators share the abstracted super-xtend, AbstractCppMakefileGenerator
>>> Ernesto Posse <eposse@xxxxxxxxxxxxx> 5/13/2016 4:48 PM >>>
Hi William. Yes, it's safe to abandon, and yes, we prefer to rebase over merge so we get a more "linear" history. Other projects have different policies, but it's rebase for us. I think our Oomph setup automatically configures the git and gerrit branch that is checked out to rebase on pull, but if not, you can always select the branch on EGit->Configure...->Rebase on pull (I don't recall the exact name of the menu items).
Hi Ernesto,
Thanks for the formatting prefs. I'll apply and amend the changes as recommended. Is it safe to 'Abandon' the extraneous change from within the Gerrit web UI?
Still cutting my teeth on the Git/Gerrit paradigm. Question. From what I read, it's often preferred to Rebase when pulling the origin/master into my local repo. Does that sound right?
- Bill
Hi William. I took a quick look, but the change of formatting makes it quite hard to see where you made changes.
The new Oomph setup sets the default formatting, but it hasn't been applied yet to most of the sources, so naturally when you save, it applies the new formatting rather than the old, so it's not your fault, but unfortunately it becomes quite hard to see the diff.
I was wondering if perhaps you could use for now, the formatting preferences I'm attaching, reformat the files you changed and push to Gerrit again?
As I commented on your other change, when pushing to Gerrit, it's preferable to do a commit amend on your existing commit, reusing the same Change-Id in the commit message rather than creating a separate commit. If you do that, Gerrit will add a patch on the existing change-set, accumulating all the changes. Let me know if you have trouble with this.
Thanks
Thanks William, sounds great! I'll take a look.
Hi Ernesto,
I pushed the cmake changes which were successfully tested on the following: Ubuntu 12.04, Fedora 20, VS 2013, VS 2015, cygwin, msys
To support generation of empty arrays, I added the ConditionalDirective class to help satisfy MSVC requirements via #ifdef. This addition necessitated the ability to suppression indentation when emitting the directives.
The RTS lib is automatically built when building the given cmake'd model projects. The model and RTS lib can be debugged/stepped on Windows via the cygwin tooling. If interested, I can provide the eclipse tooling requirements to cmake, make, and debug from within the IDE.
Apologies for some unintended space formatting NEON decided to apply that escaped my attention prior to committing. I hope I didn't make a mess of things as this was my first Gerrit experience.
- Bill
Hi William. I don't think we have any task for makefiles, so by all means feel free to make a contribution (no pun intended).
Are you an Eclipse committer? If so, you can push your contribution to Gerrit and any of the project committers can merge it. If not, you will probably have to sign a Contributor Licence Agreement (see https://wiki.eclipse.org/CLA), get an Eclipse account (if you don't already have one) and set-up your environment as described in the links below.
Feel free to ask any questions about contributing, or the code generator or runtime.
Cheers,
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|