Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

psake builds and .net 4.5 support #47

Closed
wants to merge 12 commits into from
Closed

Conversation

taliesins
Copy link

I have added toji which uses psake to build via command line. It now builds .net 4.0 and 4.5 Nuget packages.

I have upgraded the solution to .net 4.5

Some tiny additions to the code.

Upgrade to latest newtonsoft json required me to update tests around json dates.

@OJ
Copy link
Contributor

OJ commented Oct 9, 2012

Hello Taliesin,

Than you very much for your patch! I will have a look through it later this evening when I get home. I have a couple of questions:

  • Can you please let me know what was wrong with the existing build scripts that didn't meet your needs (just out of interest)?
  • Does the entire solution still build fine under Mono (Linux & Mac)?
  • Is VS 2012 now a prerequisite for Windows users?
  • Does the solution still open in MonoDevelop?

I'm in the process of finalising things for Riak 1.2 support which comes with a few changes that includes work done on the build scripts. I hadn't considered psake because it is tied to powershell and I'd rather have something that's going to work cross platform. Once I've had the chance to validate your request and assuming all is well, it'll be merged into develop and released along with v1.0.. which is coming soon.

Thank you again!
OJ

@taliesins
Copy link
Author

To be honest I have no idea about building in mono. My main reason for using psake was targeting multiple frameworks and generating nuget packages as part of the build process (stamps version number into nuget package and assembly). You also get a tried and tested scripts for builds which is "supported" for externally.

I would love to have a preview of 1.2 version. I am mucking about with riak providers (membership, role, sessionstate etc) and webhook event emitter in c# attached to rabbitmq. I am going to open source the webhook emitter once testing is complete.

PS : Thanks for this great piece of software. I think its awsome.

Tali


From: OJ Reeves notifications@github.com
To: DistributedNonsense/CorrugatedIron CorrugatedIron@noreply.github.com
Cc: Taliesin Sisson taliesins@yahoo.com
Sent: Tuesday, October 9, 2012 8:28 AM
Subject: Re: [CorrugatedIron] psake builds and .net 4.5 support (#47)

Hello Taliesin,
Than you very much for your patch! I will have a look through it later this evening when I get home. I have a couple of questions:
* Can you please let me know what was wrong with the existing build scripts that didn't meet your needs (just out of interest)?
* Does the entire solution still build fine under Mono (Linux & Mac)?
I'm in the process of finalising things for Riak 1.2 support which comes with a few changes. Once I've had the chance to validate your request and assuming all is well, it'll be merged into develop and released along with v1.0.. which is coming soon.
Thank you again!
OJ

Reply to this email directly or view it on GitHub.

@OJ
Copy link
Contributor

OJ commented Oct 9, 2012

Hi Tali,

Not a problem mate. I'm going to have to invest a bit of time over the next few days to make sure that your patch doesn't break anything on Mono. We have a few Mono users out there and I don't want to annoy them. When I've had the chance to validate that all is well I'll get back to you.

If we're going to go down the path of bringing in a build system of this magnitude (something I'd like to think about a little more) I'd like to make sure that the Mono guys can benefit from it as well, or at least have something else in place for them to make the most of.

For the most part, the build of this stuff is quite simple so perhaps bringing in something like psake might be overkill? Very keen to hear your thoughts on that, particularly what it is about psake that you think is great and what it brings to the table.

Thank you again for your pull request mate, I love it when people from the community get involved. I am very grateful for your efforts and your comments. Very happy to hear you like the library :)

Cheers!
OJ

@peschkaj
Copy link
Contributor

Hi Tali -

I lost my original comment, so this might be a bit more terse than it should be. However - thank you so much for taking the time to put this together and then actually issue a pull request instead of forking the code and running with it.

How many of these individual changes could be broken up into separate, discrete, pull requests? There are some intermingled changes (the LastModified change) where some parts are valid (the non-LastModified part) and others are not (the LastModified part - Riak is supposed to be changing this, not the client).

What benefit does psake bring?

The one change you pointed out (version number) is a change that we can and should make the change in our nuspec to push the version number into nuget magically, and probably should. Since psake is large and brings a hard dependency on PowerShell and, thus, Windows I'd be a bit hesitant to bring such a thing into CorrugatedIron.

I'm reticent to make the VS2010 -> VS2012 migration. .NET 4.0 assemblies can be used by .NET 4.5. Since we aren't using any .NET 4.5 features, I'm not keen to make a migration for no other purpose than bumpin' the version and requiring an upgrade in dev environment.

@taliesins
Copy link
Author

Hi Jermiah,

I was not aware that it was mono friendly to begin with. If there is a cross platform solution that could be used I would defiantly vote for it. Perhaps we could go the root of bash script for linux build and powershell script for windows build? PSake syntax is pretty similar to Rake in how to structure the build. To be honest I dont mind either as long as I get a nice nuget package at the end of it. 

Does this mean that Riak will override the specified last modified? I was hoping to be able to set it from the client. Consider the case of dumping files into Riak as a nice distributed file system. I would like to use the last modified date time from the file.

Tali


From: Jeremiah Peschka notifications@github.com
To: DistributedNonsense/CorrugatedIron CorrugatedIron@noreply.github.com
Cc: Taliesin Sisson taliesins@yahoo.com
Sent: Friday, October 12, 2012 12:32 AM
Subject: Re: [CorrugatedIron] psake builds and .net 4.5 support (#47)

Hi Tali -
I lost my original comment, so this might be a bit more terse than it should be. However - thank you so much for taking the time to put this together and then actually issue a pull request instead of forking the code and running with it.
How many of these individual changes could be broken up into separate, discrete, pull requests? There are some intermingled changes (the LastModified change) where some parts are valid (the non-LastModified part) and others are not (the LastModified part - Riak is supposed to be changing this, not the client).
What benefit does psake bring?
The one change you pointed out (version number) is a change that we can and should make the change in our nuspec to push the version number into nuget magically, and probably should. Since psake is large and brings a hard dependency on PowerShell and, thus, Windows I'd be a bit hesitant to bring such a thing into CorrugatedIron.
I'm reticent to make the VS2010 -> VS2012 migration. .NET 4.0 assemblies can be used by .NET 4.5. Since we aren't using any .NET 4.5 features, I'm not keen to make a migration for no other purpose than bumpin' the version and requiring an upgrade in dev environment.

Reply to this email directly or view it on GitHub.

@peschkaj
Copy link
Contributor

If a client sends in LastModified you can end up with siblings, especially when you have significant clock drift between client and server or when the use neglects to set LastModified to the same time zone as the server.

Users can, however, send in custom headers with the Riak object, so X-MyDFS-Clone-LastModified is perfectly acceptable. Besides, users can do sneaky things with file systems and not record last modification time. The side effect of that in Riak would be entertaining, to say the least.

You can also use 2i or just create custom properties on your file system driver. RiakFuse used to exist as a project somewhere, as did Luwak. I'm not sure about RiakFuse's status, but I do know that Luwak probably won't work on any Riak that's reasonably new.


Jeremiah Peschka, Managing Director, Brent Ozar PLF, LLC
Microsoft SQL Server MVP

On Oct 11, 2012, at 11:31 PM, Taliesin Sisson notifications@github.com wrote:

Hi Jermiah,

I was not aware that it was mono friendly to begin with. If there is a cross platform solution that could be used I would defiantly vote for it. Perhaps we could go the root of bash script for linux build and powershell script for windows build? PSake syntax is pretty similar to Rake in how to structure the build. To be honest I dont mind either as long as I get a nice nuget package at the end of it.

Does this mean that Riak will override the specified last modified? I was hoping to be able to set it from the client. Consider the case of dumping files into Riak as a nice distributed file system. I would like to use the last modified date time from the file.

Tali


From: Jeremiah Peschka notifications@github.com
To: DistributedNonsense/CorrugatedIron CorrugatedIron@noreply.github.com
Cc: Taliesin Sisson taliesins@yahoo.com
Sent: Friday, October 12, 2012 12:32 AM
Subject: Re: [CorrugatedIron] psake builds and .net 4.5 support (#47)

Hi Tali -
I lost my original comment, so this might be a bit more terse than it should be. However - thank you so much for taking the time to put this together and then actually issue a pull request instead of forking the code and running with it.
How many of these individual changes could be broken up into separate, discrete, pull requests? There are some intermingled changes (the LastModified change) where some parts are valid (the non-LastModified part) and others are not (the LastModified part - Riak is supposed to be changing this, not the client).
What benefit does psake bring?
The one change you pointed out (version number) is a change that we can and should make the change in our nuspec to push the version number into nuget magically, and probably should. Since psake is large and brings a hard dependency on PowerShell and, thus, Windows I'd be a bit hesitant to bring such a thing into CorrugatedIron.
I'm reticent to make the VS2010 -> VS2012 migration. .NET 4.0 assemblies can be used by .NET 4.5. Since we aren't using any .NET 4.5 features, I'm not keen to make a migration for no other purpose than bumpin' the version and requiring an upgrade in dev environment.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.

@OJ
Copy link
Contributor

OJ commented Oct 14, 2012

+1 to @peschkaj 's comment. The last modified date isn't something that should have semantic meaning to the content. If you need that information, meta data and/or fields in the data are better solutions (and you have better control of them).

@taliesins While the current "build" system is clunky, it does generate nuget packages as it currently stands. I do have a question though: do you generate your own nuget packages for internal use?

Cheers!

@peschkaj
Copy link
Contributor

I've created a new issue where we can discuss potential build systems at #48.

At this point, there are two options available - I can cherry pick specific pull requests or you can resubmit them individually. Right now I know I would not reject the following commits:

  • 8f08229 - .NET 4.5/VS2012
  • 8f08229 - .NET 4.5/VS2012
  • fb08814 - This is more than an upgrade to partial trust attributes but isn't documented that you kicked RiakObject into shape (we use commit logs to generate our changelogs)
  • ecfa83c - doesn't belong in the client
  • 74f363a - I've commented about my thoughts on the size and dependencies of psake before and opened Issue 48 for further discussion of what makes the most sense for CI.

Commits that are good to go:

All in all, this pull request touches 217 files and introduces some huge changes. It also includes a bunch of binary files and I don't think we should be versioning DLLs that are hosted by NuGet. If we are right now, then OJ and I should be beaten mercilessly and then remove the binaries from version control.

Would you be adverse to submitting several smaller pull requests?

@Iristyle
Copy link

Just to chime in 2c on the build stuff, since I do a lot of build engineering at work, and have built a number of supplemental tasks for Psake, that I have here at the Midori repo.

If you want to go cross-platform on the builds, then Powershell / Psake / Toji is not the best fit.

You have a few choices if you want to ensure building on all platforms that Mono is supported

  • Rake (+ Albacore)
    • I wouldn't recommend this due to these dependencies being a pain on Windows... not saying that it can't be done, but...
  • Grunt + ShellJS (optional, but helps to normalize shell commands on top of Node if you need them) + a simple custom grunt plugin to run msbuild / xbuild.
    • Node is such a lightweight redistributable that this option is pretty enticing - easy to install on most Oses (and even bootstrap as part of the build if you wanted to)
    • A grunt-msbuild plugin would detect the OS and perform a which (using ShellJS) to find msbuild / xbuild and call appropriately, as an example.
  • All MSbuild -- you might be able to get away with this -- by writing custom inline tasks in MSBuild to do some of the things you need. Having gone down the shoehorn procedural tasks into MSBuild xml approach, I would recommend strongly against this if you value your sanity.

So, you can see an example of how libgit2sharp integrates with Travis CI and builds on Mono. It is surprisingly straightforward.

If you wanted to setup Grunt build to behave a little differently locally versus under TravisCI, heres an example.

The other major win for building with TravisCI, is that you can get build status on pull requests. So if someone breaks the build in some way (compiler, analysis checks like Gendarme, tests, etc) then you know before pulling -- which is really important IMHO for project maintainers to know.

If you guys decide you want to go the TravisCI / Grunt approach, I can probably lend a hand here.

@OJ
Copy link
Contributor

OJ commented Nov 17, 2012

So here's my current stance:

  • Psake is just "too much" for CI. It's not cross-platform and it's way too big.
  • CI is essentially a single DLL, there's no need for an extreme build system.
  • A simple build file which can be invoked via msbuild or xbuild is all that's required to get things to build.
  • This can be wired into travis quite easily to verify the mono build.

Anything more than that, such as pulling in custom build systems, just seems like huge overkill to me.

@OJ
Copy link
Contributor

OJ commented Nov 18, 2012

Hi @taliesins,

I'm looking for ways to pull bits and pieces of this pull request into CI. It's proving a bit hard without the changes made that @peschkaj requested. Any chance you can take these on? We want to be able to give you credit for the work you have done.

Thanks!
OJ

@Iristyle
Copy link

Yeah, was only throwing info in there since I've spent a lot of time on build systems....

Not necessarily saying you needed anything more advanced than xbuild / msbuild right now. But did want to warn against the msbuild stuff spiraling out of control if you start to add more than just tests (FxCop / Gendarme / StyleCop / etc) -- been there, done that -- it doesn't scale well.

@peschkaj
Copy link
Contributor

peschkaj commented Dec 6, 2012

Closing the pull request - the changes that we're going to accept have been merged in from other paths.

@peschkaj peschkaj closed this Dec 6, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants