[UrJTAG-dev] GitHub + Travis

[Tomasz CEDRO]

I am testing Travis with GitHub, that is a well integrated build test
automation, that triggers Travis build tests on git push.

I really think we should consider moving to GitHub.. or implement
something like Travis on current SF sourcebase.. :-)

[Tomasz CEDRO]

Check this out folks, it can even test build the pull requests live
before code is committed to the upstream! :-)

https://travis-ci.org/cederom/LibSWD

[Kolja Waschk]

Post by Tomasz CEDRO
I am testing Travis with GitHub, that is a well integrated build test
automation, that triggers Travis build tests on git push.

I agree that UrJTAG would really benefit from continuous
testing/integration. Especially these various bits about this or that
Cygwin/MinGW detail that are easily missed if you don't always check
compilation on each platform.

As you see from the past few postings here, it didn't became easier to
compile UrJTAG for Windows. Maybe we should try CMake instead of
autotools soon; it is usually better suited for cross-platform projects
(at least in my experience).

Still waiting for Mike to comment re: UrJTAG org and moving there. He's
has been doing most of the patch discussion and integration in the past
years. I hope he's just on vacation.

Kolja

[Geert Stappers]

Post by Kolja Waschk

Post by Tomasz CEDRO
I am testing Travis with GitHub, that is a well integrated build test
automation, that triggers Travis build tests on git push.

I agree that UrJTAG would really benefit from continuous
testing/integration. Especially these various bits about this or that
Cygwin/MinGW detail that are easily missed if you don't always check
compilation on each platform.

CI is nice indeed.

What it takes to let Continuous Integration also do Cygwin/MinGW
is unknown to me.

Right now we, the people who care about urjtag,
should _not_ make CI a blocking issue.

Post by Kolja Waschk
As you see from the past few postings here, it didn't became easier to
compile UrJTAG for Windows. Maybe we should try CMake instead of
autotools soon; it is usually better suited for cross-platform projects
(at least in my experience).

And if a volunteer shows up to port to mesos and ninja, also fine.

Post by Kolja Waschk
Still waiting for Mike to comment re: UrJTAG org and moving there. He's
has been doing most of the patch discussion and integration in the past
years. I hope he's just on vacation.

That vacation explains why Mike missed 2017-02-15 the e-mail about lower SVN
in favor of git (on SF). On 2017-02-21 he posted that SVN content was push
to git (on SF). This is the first ML posting that it was not needed.

While vapier is enjoying vaction we can work on (our local) git.
And/or find other ways to get urjtag rolling again :-)


Groeten
Geert Stappers

P.S.
I hope that the CC did help to get attention from Mike for urjtag

[Tomasz CEDRO]

Well I hope Mike is fine.. wish he comes back soon and we can clean up
and reactivate the project :-)

GCC+GLANG+MINGW intergation in Travis is already there as easy as
adding one or two lines of code.

It really easily shows what would be build problems on a different platforms.

I just think that there is no sense to pull the project in a current fashion.

Also the build problems could be easily resolved with help of
GitHub+Travis verification and cooperation platform :-)

[Benjamin Henrion]

Post by Geert Stappers

Post by Kolja Waschk

Post by Tomasz CEDRO
I am testing Travis with GitHub, that is a well integrated build test
automation, that triggers Travis build tests on git push.

I agree that UrJTAG would really benefit from continuous
testing/integration. Especially these various bits about this or that
Cygwin/MinGW detail that are easily missed if you don't always check
compilation on each platform.

CI is nice indeed.
What it takes to let Continuous Integration also do Cygwin/MinGW
is unknown to me.
Right now we, the people who care about urjtag,
should _not_ make CI a blocking issue.

Post by Kolja Waschk
As you see from the past few postings here, it didn't became easier to
compile UrJTAG for Windows. Maybe we should try CMake instead of
autotools soon; it is usually better suited for cross-platform projects
(at least in my experience).

And if a volunteer shows up to port to mesos and ninja, also fine.

I forked ninja a year ago, I am willing to spend time on it.

Autotools are trying to detect platforms from 1974.

Cmake is an improvement.

And Google is migrating most of the Android codebase to Ninja to
speedup the configure part.
--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - [phone] - [phone]
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

[Tomasz CEDRO]

Post by Benjamin Henrion
I forked ninja a year ago, I am willing to spend time on it.
Autotools are trying to detect platforms from 1974.
Cmake is an improvement.
And Google is migrating most of the Android codebase to Ninja to
speedup the configure part.

never used cmake in my projects but building is also easy :-)

what is ninja and what we would need that? that could be another good
hint from you after travis :-)

[Benjamin Henrion]

Post by Tomasz CEDRO

Post by Benjamin Henrion
I forked ninja a year ago, I am willing to spend time on it.
Autotools are trying to detect platforms from 1974.
Cmake is an improvement.
And Google is migrating most of the Android codebase to Ninja to
speedup the configure part.

never used cmake in my projects but building is also easy :-)
what is ninja and what we would need that? that could be another good
hint from you after travis :-)

https://ninja-build.org/
https://ninja-build.org/manual.html

You have to make one .ninja file per platform (one for linux, one for
osx, one for windows):

And then try to build it with:

ninja configure
ninja build

--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - [phone] - [phone]
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

[Tomasz CEDRO]

Post by Benjamin Henrion
https://ninja-build.org/
https://ninja-build.org/manual.html
You have to make one .ninja file per platform (one for linux, one for
ninja configure
ninja build

so this NINJA thing is an alternative to Travis or CMake or configure?

why better than CMake?

[Kolja Waschk]

I also had somewhat good experiences with Ninja, but no really stringent
reason to use it. To me it seems that CMake is better regarding
Cross-Platform decisions, Ninja with regard to speed when doing rebuilds
after only a few code changes?

Kolja

[Benjamin Henrion]

Post by Kolja Waschk
I also had somewhat good experiences with Ninja, but no really stringent
reason to use it. To me it seems that CMake is better regarding
Cross-Platform decisions, Ninja with regard to speed when doing rebuilds
after only a few code changes?

I also think cmake is better documented, and for such a small tool, it
is good enough.
--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - [phone] - [phone]
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

[Tomasz CEDRO]

Post by Kolja Waschk
I also had somewhat good experiences with Ninja, but no really stringent
reason to use it. To me it seems that CMake is better regarding
Cross-Platform decisions, Ninja with regard to speed when doing rebuilds
after only a few code changes?

Yea for Android it could be better when you need to rebuild all stuff
when you make small changes speed is important as I find Android
Studio extremely slow now. But here for UrJTAG CMake should be
enough..?

[Geert Stappers]

Post by Geert Stappers

Post by Kolja Waschk

Post by Tomasz CEDRO
I am testing Travis with GitHub, that is a well integrated build test
automation, that triggers Travis build tests on git push.

I agree that UrJTAG would really benefit from continuous
testing/integration. Especially these various bits about this or that
Cygwin/MinGW detail that are easily missed if you don't always check
compilation on each platform.

CI is nice indeed.
What it takes to let Continuous Integration also do Cygwin/MinGW
is unknown to me.
Right now we, the people who care about urjtag,
should _not_ make CI a blocking issue.

And whoever wants to play with whatever CI tooling
is very welcome to do so.



Groeten
Geert Stappers