[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Remote enabling auto tools
|
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
