Silence warning spam on clang

[in3otd]

since this is probably due to the clang version used by Travis and maybe to the ccache usage, fix it only there for the moment

[in3otd]

oh well, any idea why Travis is not starting?

[andresmmera]

./configure CXXFLAGS="-Wno-unused-command-line-argument" --disable-dependency-tracking --with-gtest=/tmp/gtest --enable-doc

Maybe it should be:

./configure CXXFLAGS="-Wno-unused-command-line-argument --disable-dependency-tracking --with-gtest=/tmp/gtest --enable-doc"

Here they say the most common reason of failure is a bad YAML syntax.

[in3otd]

thanks for the link, I learned that Travis has a hidden "requests" page with all the requests details: indeed it was a syntax error since I did not pay attention that the added comment ended up in the middle of the if shell command

[andresmmera]

Well, I tried to do the 'request' trick, as detailed in the link above,... but it showed just a blank window... Good to know it worked on your side.

On Sat, 22 Sep 2018, 21:34 in3otd, notifications@github.com wrote:

thanks for the link, I learned that Travis has a hidden "requests https://travis-ci.org/Qucs/qucs/requests" page with all the requests details: indeed it was a syntax error [image: image] https://user-images.githubusercontent.com/9018179/45921038-d2cbee80-bead-11e8-8b4d-8b0e77989fef.png since I did not pay attention that the added comment ended up in the middle of the if shell command

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Qucs/qucs/pull/870#issuecomment-423767903, or mute the thread https://github.com/notifications/unsubscribe-auth/AMkfEaJLY27k4wZiOplFj_wY4UaSUspOks5udpDSgaJpZM4W1SFz .

[in3otd]

seems we need to pass the CXXFLAGS also to make distcheck as it retriggers configure.

By the way, why do we need to pass DISTCHECK_CONFIGURE_FLAGS to make distcheck? It seems it uses almost the same option as the previously run configure.

@andresmmera maybe you need to be logged in to Travis, the link I posted works fine for me. The requests page can be accessed also from the menu on the left

[in3otd]

seems to be ok now, please double check and merge :grin:

[felix-salfelder]

looks good to me. thanks.

why not 'develop'? are we doing everying twice now?

[in3otd]

we have some stuff waiting to be merged in both develop and release-0.0.20 so it will need to go in both. I guess we need separate PRs for the two branches.

[felix-salfelder]

On Mon, Sep 24, 2018 at 03:05:31AM -0700, in3otd wrote:

we have some stuff waiting to be merged in both develop and release-0.0.20 so it will need to go in both. I guess we need separate PRs for the two branches.

could as well rebase onto develop, if there has to be a difference. or simply tag when ready.

[in3otd]

not sure I understand what should be done here: I had in mind this page which says in the top picture "bugfixes from release branch may be continuously merged back into develop" so I thought we merge this (Travis) bugfix into release-0.0.20 and at the same time into develop, as without it the Travis CI does not work in any branch, it seems.

[felix-salfelder]

in [1], the release branch contains fixes only and is merged back into develop. this does not work for us, as there is now unreviewed and non-bugfix stuff in that branch. we can't merge either way now, and the branches are diverging... (totally not the intent of [1]).

a rebase (i.e. regular rebase on top of develop) will approximately amend this, i.e. fix the diversion and reduce the need for duplicate reviews.

[1] https://nvie.com/posts/a-successful-git-branching-model/

[guitorri]

We need this on release-. So, I am merging it.

I don't see why we cannot continuously merge release- into develop. The release- (or rather master) will have to be merged anyway into develop later on. Another alternative is to just cherry pick this patch into develop just to keep CI running and later we see the merge conflicts.

[guitorri]

See #873, it seems safe to me.