Apologies, it works with #14 which I just retested using a new Papyrus-RT installation. I rebased earlier today @ #15 via the Gerrit web console. Apparently this didn't work very well.
Strange. I did a "Fetch from Gerrit..." with patch #15 and got an empty commit.
Hi Ernesto,
When I checkout the latest patch, I get all the files. But it seems that Gerrit is only showing what changed in the recent patches. I'll try to figure out what's going on, and follow up asap.
- Bill
Hi William. I think something may have gone wrong with your rebases. When I look at Gerrit, up to patch #11 I see all the new and modified files, but then in #12 there is only one (CppCodePattern.java) and #13, #14 and #15 are empty, so submitting #15 won't do anything.
Do you remember what you did in those last patches?
Hi Ernesto,
I rebased the CMake work, and tested/verified on Ubuntu (12.04), Eclipse on Windows 10 (via Cygwin), and VS 2015.
Also verified the native Makefile (and the RTS Makefile) on Ubuntu.
To review the diff since your last fixup, I suggest comparing #14 to #9. - Bill
>>> "William Byrne" <williamb@xxxxxxxxxx> 5/18/2016 10:53 PM >>>
Hi Ernesto,
Here's a list of the changes made in patch #10: - made the copyright changes
- added a safeguard (with a notice) for the existing Makefile(s) to prevent an overwrite by CMake generated Makefile(s)
- made a Windows CMake config fix for an issue discovered during testing
- removed the genCMake flag enabling automatic generation of both the existing Makefile and the new CMakeLists.txt outputs.
- verified the changeset on the Ubuntu workstation making sure the existing Makefiles for both the modeled projects and RTS lib build, link, and execute
And thankfully, Hudson is happy.
Excluding additional documentation, I have nothing else planned for this changeset.
- Bill
>>> "William Byrne" <williamb@xxxxxxxxxx> 5/18/2016 4:39 PM >>>
Excellent.
I've already made the copyright changes, and currently testing/fixing a few small things. I expect to post the changes this evening.
BTW, thanks for correcting the "expected_src". Not sure why the order of member variables differed in my case. Perhaps I'm running the standalone generator incorrectly.
>>> Ernesto Posse <eposse@xxxxxxxxxxxxx> 5/18/2016 4:04 PM >>>
That looks great!
We have discussed about your contribution, and we'll merge it before the freeze, and I see that you already signed a CLA, and luckily the contribution is less than 1000 lines, so we can merge it without doing a CQ, but since this is not in the feature set for 1.0 and since we haven't had time to test it we are not going to publicize it yet, as a 1.0 feature. I think we'll be able to publicize it in 1.0.1, though.
Before merging it, could you update the copyright licences of the new files (and only the new files) replacing "The Eclipse Foundation" and "CEA LIST" to you or your company or whichever is appropriate? (and keeping the EPL notice of course)
Exactly, but that's only for the rts.lib and rtsd.lib in the case of MSVC..
All the remaining build pieces such as the solution and project files get created under the build subdirectories I show for MyModel below in my previous message. An example of two build tools side-by-side for the same model project: Here are some msvc pics: ![]( "The sender attempted to attach a file, but the file is missing.
If you need the file, have the sender resend it.
cid:UJPWUMWGSOLU.build-msvc.jpg")
Here are some cygwin pics:
I see, so you set the TARGETOS and BUILD_TOOLS environment variables accordingly, and in particular, in Visual Studio you set them to 'windows' and 'x86-VisualC++-12.0' respectively?
Building and debugging for both the modeled project and RTS occur within the Visual Studio IDE. Both VS 2013 & 2015 were tested. Having the ability to step into both the project and RTS was my primary motivation for introducing CMake. It's also possible to build the MSVC artifacts via the command line; e.g., cmake --build ..
It's also possible to have side-by-side generation for the various built tools; e.g.,
MyModel src -- build-msvc-2013 -- build-msvc-2015 -- build-msys -- build-cygwin
Two points regarding the RTS library. 1) It's built and installed on demand as a dependency. 2) It's installed under the following directory:
<umlrt.rts>/lib/<os>/<build-tool>/<config>
Hi again William. We have been talking about your feature and we are curious about your testing on Windows under Visual Studio. The RTS has some Windows support but it has a different API, and my understanding is that using Visual Studio you are compiling with Microsoft's compiler, not with gcc. Isn't that the case? Your instructions are for Eclipse+Cygwin, and the RTS should work on Windows under Cygwin, but what do you do on VS?
Hi,
Yes, the templates configured in the source projects indicate CEA LIST because the majority of contributions to Papyrus are from CEA LIST.
It would be nice to make it more dynamic, using some kind of variable that the developer can define in the local workspace. If anyone can suggest how to make such improvement, I’ll be happy to realize it in the project configurations. For myself, I have shell scripts that automatically update the copyright headers of files in my git index, so I haven’t much worried about it.
Okay. I believe those were inserted by the Eclipse
templates. Will correct.
>>> Ernesto Posse
<eposse@xxxxxxxxxxxxx> 5/18/2016 12:54 PM
>>>
By the way, we noticed that in the files you
contributed you've added "The Eclipse Foundation" and "CEA LIST" as
the copyright holders. I think you cannot attribute your files to
them. They should have your copyright, but preserving the EPL.
>> I assume that having a CMakeLists.txt would not have
any effect if CMake is not used, correct?
>> In particular, generating it would not conflict with
the makefiles?
Yes, providing CMake is executed from a directory other than
that containing the current Makefile. I'm adding a safety to ensure
this.
I assume that having a CMakeLists.txt would not have
any effect if CMake is not used, correct? In particular, generating
it would not conflict with the makefiles?
Hi Ernesto,
I realize that flag presents an issue regarding how it gets
enabled. How do you feel about generating both the existing
Makefile along with the new CMakeLists.txt file? When I get back to
my office this evening, I can enable both modes and verify.
- Bill
I forgot to ask. I looked over your documentation,
but it looks to me that it doesn't say how to enable the CMake
build. Given that the cmakeGen flag in CppCodePattern doesn't seem
to be set anywhere and there is no UI support for it, I'm guessing
that this can only be enabled if the user is executing the
generator from the development environment, or am I missing
something?
William, I pushed a patch trying to solve the
testing issue, although I'm not sure what's the problem. Also,
there was a problem with the existing CppMakefileGenerator: when
you formatted it, the tabs were replaced by spaces, resulting in a
bad makefile.
Anyway, you can get the patch by selecting the repo in the Git
Repositories view, right-click->Fetch from Gerrit... and under
"Change" select 72661-<patch-number>.
Perfect! Thanks!
Hi Charles,
I provided PDF guides for Windows and Ubuntu up-thread @
5/15/2016 9:51 PM.
- Bill
>>> "charles+zeligsoft.com" <charles@xxxxxxxxxxxxx> 5/16/2016 8:31 PM
>>>
Hi Bill,
Good and thanks for your efforts with this. It is
appreciated.
I will defer to Ernesto and Barry for the review of the
technical aspects.
Will there be a need to either user or toolsmith documentation
for this capability?
Sincerely,
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
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@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@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@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
|
