Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-dev] [cdt-dev] Remote enabling auto tools

Interesting. I'm guessing the PayPal plug-in takes care of everything for you too. And they are using it in two directions since they mentioned they also rsync back the files from the include path to enable local indexing. The writing I've seen is that you just need to rsync in each direction in 'newer' mode and you get bidirectional. Not clean though.

At any rate, an interesting discussion. The rsync thing hit home for me since I was recently using it when managing deployment of files to my personal web server. And we have rsync on our QNX/BlackBerry targets which we could use for syncing files to. It's an old solution but I think it has it's place.

Doug.



From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Greg Watson [g.watson@xxxxxxxxxxxx]
Sent: Tuesday, March 25, 2014 8:52 AM
To: CDT General developers list.
Cc: Parallel Tools Platform general developers
Subject: Re: [cdt-dev] Remote enabling auto tools

Cross posting to the ptp-dev list so the developers can provide more information.

The beauty of the git solution is that you don’t need to know how it works, it just does everything for you.

There is an extension point that allows different sync providers to be used. We had a prototype rsync provider for a while, but it wasn’t being actively developed. If someone want’s to see if it can be resurrected, that would be fine. However, since rsync is only unidirectional, it is also more complicated to set up to get bi-directional syncing working.

Greg

On Mar 24, 2014, at 11:28 PM, Doug Schaefer <DSchaefer@xxxxxxx> wrote:

Ah, that makes sense. It's an interesting choice. Maybe that's why people miss it. It's not obvious how it works. Doesn't the index keep growing and growing each time you sync files? Why is it faster than rsync? I assume you guys have a wiki describing it. Could you share it with the list here? Thanks!


From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Beth Tibbitts [beth@xxxxxxxxxx]
Sent: Monday, March 24, 2014 11:17 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Remote enabling auto tools

The git use for synchronized projects is entirely independent of git for src code repo.

...Beth

Beth Tibbitts


On Mon, Mar 24, 2014 at 10:24 PM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
One thing I never understood about the git solution, what if my project is already in git. Do I have to do a commit every time I want to build?

rsync is pretty powerful with lots of filtering options and is as old as dirt. I think there's room for more than one solution.

Doug.

________________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Greg Watson [g.watson@xxxxxxxxxxxx]
Sent: Monday, March 24, 2014 9:47 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Remote enabling auto tools

FYI, PTP has been able to do this for three years. I presented our at EclipseCon 2012:https://www.eclipsecon.org/2012/sessions/automatic-remote-project-synchronization-using-git

We looked at using rsync for our synchronized projects but settled on using git because it is faster, allows projects to be filtered, and is more flexible. We also allow synchronizing any type of project, not just CDT projects. In addition, we can synchronize to multiple remote hosts simultaneously, and have integration with environment management systems such as modules and softenv.

It’s a bit disheartening to see people re-implement the same thing without checking to see if someone has done it before.

Greg

On Mar 24, 2014, at 4:34 PM, Doug Schaefer <DSchaefer@xxxxxxx> wrote:

> Speaking of remote, what did you guys think of PayPal's strategy of using rsync and ssh for dealing with remote projects? Builds are fully done on the remote machine and rsync is used to sync the two together. Seems pretty obvious now that I look at it.
>
> Doug.
> ________________________________________
> From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Jeff Johnston [jjohnstn@xxxxxxxxxx]
> Sent: Monday, March 24, 2014 4:23 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Remote enabling auto tools
>
> Looks good.  I will start looking at making the changes on the Autotools
> side other than changing to the new CommandLauncher.
>
> -- Jeff J.
>
> ----- Original Message -----
>> From: "Greg Watson" <g.watson@xxxxxxxxxxxx>
>> To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
>> Sent: Friday, March 21, 2014 5:59:57 PM
>> Subject: [cdt-dev] Remote enabling auto tools
>>
>> Jeff,
>>
>> Here’s a summary of what I think needs to happen to make this work:
>>
>> 1. AutotoolsNewProjectNature#getBuildCommandsList() needs to check for a
>> synchronized project builder (ID:
>> org.eclipse.ptp.rdt.sync.cdt.core.SyncBuilder) in addition to the CDT
>> managed project builder.
>>
>> 2. PTP to provide a drop-in replacement for CommandLauncher that uses the
>> project to determine if the command should be launched locally or remotely.
>>
>> 3. Autotools needs to refresh the project after creating the build directory,
>> but prior to starting the build, so that in the case of synchronized
>> projects, the build directory is replicated on the target. This should
>> possibly be done in AutotoolsNewMakeGenerator#regenerateMakefiles(). The
>> following code should achieve this:
>>
>>      IRemoteResource remRes =
>>      (IRemoteResource)getProjectI().getAdapter(IRemoteResource.class);
>>      if (remRes != null) {
>>              remRes.refresh(progressMonitor);
>>      }
>>
>> 4. AutotoolsNewMakeGenerator#getPathString() checks to see if the local
>> machine is Windows. This needs to be modified to use something along the
>> following lines:
>>
>> private String getOSName() {
>>      IRemoteResource remRes =
>>      (IRemoteResource)getProject().getAdapter(IRemoteResource.class);
>>      if (remRes != null) {
>>              URI uri = remRes.getActiveLocationURI();
>>              IRemoteServices remServices = RemoteServices.getRemoteServices(uri);
>>              if (remServices != null) {
>>                      IRemoteConnection conn =
>>                      remServices.getConnectionManager().getConnection(uri);
>>                      if (conn != null) {
>>                              return conn.getProperty(IRemoteConnection.OS_NAME_PROPERTY);
>>                      }
>>              }
>>      }
>>      return Platform.getOS();
>> }
>>
>> I don’t think the build environment will be an issue, but that’s something we
>> can check later.
>>
>> Let me know if you think of anything else.
>>
>> Regards,
>> Greg
>>
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top