Skip to main content

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

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


Back to the top