search

mauke / Function-Parameters

Function::Parameters - define functions and methods with parameter lists ("subroutine signatures")
https://metacpan.org/pod/Function::Parameters
18 stars 19 forks source link

Add a Travis configuration #14

Closed schwern closed 9 years ago

schwern commented 9 years ago

Now we can add compiler flags to our heart's content.

@mauke You need to turn Travis on for your repository after pushing this in https://travis-ci.org/profile

This is after discussion in #13.

mauke commented 9 years ago

How do I tell Travis what options to configure perl with?

And how does Travis notify my editor about compiler warnings?

schwern commented 9 years ago

And how does Travis notify my editor about compiler warnings?

I'm sure you already know the answer to this. And I'm sure your personal editor is set up with all sorts of magic. Are you mildly inconvenienced by this change? Now think about that when you tell contributors they should spend hours recompiling their default C compiler so you don't have to change what you type.

Getting contributors means making it as easy as possible to contribute. Contributors are volunteers and aren't going to spend hours or even minutes doing special stuff for the privilege of working on your project for free. This means you can no longer tailor the project to your personal quirks and configurations, you have to think about everybody's quirks and configurations. That's the trade off!

You can still tailor things to how you want, you just can't hard wire it as the default. I am quite sure you're capable of writing an editor macro that runs make -f TravisMakefile at the push of a button. It's slightly less convenient for you, but way more convenient for everybody else.

What Travis provides is a consistent, clean testing environment for everyone without requiring extra developer work or specially configured environments or even remembering to run it. It just happens. My commits will be as well tested as your commits without relying on you to remember to run some magic only you can run. Then everyone can jump in and contribute and mistakes will be caught automatically. You can still also run extra tests and things yourself.

So that's the proposition. More contributors at the expensive of some of your personal convenience. But it's really not a zero sum game. Once Travis is configured you no longer have to personally check every commit, that's handled for you. That's convenient! Then things like perlcritic and perltidy can be added automatically... and you can spend more time coding and less time running tests with obscure flags.

How do I tell Travis what options to configure perl with?

Travis has a few more Perls than I listed which can be used with the -extras flag. The big one is that they're compiled with threads.

If you really want to you can use the install target to download and build Perl. It's slow, but that's not our problem so long as it gets done.

If that's not enough, multitest can stay and you can supplement the Travis tests with whatever extra Perls you have installed.

mauke commented 9 years ago

I'm sure you already know the answer to this. And I'm sure your personal editor is set up with all sorts of magic. Are you mildly inconvenienced by this change? Now think about that when you tell contributors they should spend hours recompiling their default C compiler so you don't have to change what you type.

On the other hand, you're just some random guy on the internet who insists on breaking my working setup just because he can't be arsed to fix his broken compiler.

Contributors are volunteers and aren't going to spend hours or even minutes doing special stuff for the privilege of working on your project for free.

I am quite sure you're capable of writing an editor macro that runs make -f TravisMakefile at the push of a button.

I agree, but you seem to be forgetting that I am one of those contributors. In fact, looking at the commit history, I am the main contributor, so why should I spend minutes or even hours to change my working setup? I'm a volunteer, too.

If that's not enough, multitest can stay and you can supplement the Travis tests with whatever extra Perls you have installed.

If anything, Travis will be an addition to the existing stuff, not a replacement. You don't seem to understand what maint/eumm-fixup.pl (formerly GNUmakefile) does or how it's used, and you didn't ask the main user (me) about his workflow.

maint/eumm-fixup.pl does 3 (maybe 4) different things. Travis can maybe replace 1 of them, badly.

schwern commented 9 years ago

You're right that you're the biggest contributor. You're also the only contributor. If you continue to tailor the project to your own needs, it will stay that way. It's very circular.

I've shown I'm quite happy to do work. I don't think it's too much to ask that I (and every other OS X user) can work without having to spend a few hours recompiling my system C compiler when the trade off is you have to change a few editor macros. It seems it is. That's a choice you get to make for your project. So I'll take my time elsewhere.