Deprecate autotools and fix versioning, build with MinGW #434

xor-gate · 2016-06-18T14:24:05Z

Now CMake loads the version from TRAVIS_TAG, git describe --always or local .version.
Implementation of discussion in #431, for v.2.0.0

@texane what do you think? Could you review-merge?

texane · 2016-06-18T14:33:51Z

Does it still compile on Windows with Mingw32 ? Does not look so
to me (ie. doc/mingw.md). I agree to remove autotools, but all the
currently supported systems must work and the corresponding
doc be up to date.

Appart from that, looks fine to me.

2016-06-18 16:24 GMT+02:00 Jerry Jacobs [email protected]:

Now CMake loads the version from TRAVIS_TAG, git describe --always or
local .version.
Implementation of discussion in #431
#431, for v.2.0.0

@texane https://github.com/texane what do you think? Could you

review-merge?

You can view, comment on, or merge this pull request online at:

#434
Commit Summary

Deprecate autotools and load version from TRAVIS_TAG, git command or
local .version file

File Changes

M .travis.sh
https://github.com/texane/stlink/pull/434/files#diff-0 (21)

M .travis.yml
https://github.com/texane/stlink/pull/434/files#diff-1 (11)

A .version https://github.com/texane/stlink/pull/434/files#diff-2
(1)

D ACKNOWLEDGMENTS
https://github.com/texane/stlink/pull/434/files#diff-3 (2)

D AUTHORS https://github.com/texane/stlink/pull/434/files#diff-4
(19)

M CMakeLists.txt
https://github.com/texane/stlink/pull/434/files#diff-5 (72)

D COPYING https://github.com/texane/stlink/pull/434/files#diff-6
(27)

M ChangeLog
https://github.com/texane/stlink/pull/434/files#diff-7 (9)

D Makefile.am
https://github.com/texane/stlink/pull/434/files#diff-8 (59)

D NEWS https://github.com/texane/stlink/pull/434/files#diff-9
(0)

D README https://github.com/texane/stlink/pull/434/files#diff-10
(335)

D README.md
https://github.com/texane/stlink/pull/434/files#diff-11 (1)

A README.md
https://github.com/texane/stlink/pull/434/files#diff-12 (251)

D TODO.md https://github.com/texane/stlink/pull/434/files#diff-13
(11)

D autogen.sh
https://github.com/texane/stlink/pull/434/files#diff-14 (2)

D configure.ac
https://github.com/texane/stlink/pull/434/files#diff-15 (59)

R doc/build_mingw.md
https://github.com/texane/stlink/pull/434/files#diff-16 (3)

A doc/release.md
https://github.com/texane/stlink/pull/434/files#diff-17 (10)

D src/tools/gui/Makefile.am
https://github.com/texane/stlink/pull/434/files#diff-18 (30)

M src/usb.c
https://github.com/texane/stlink/pull/434/files#diff-19 (2)

Patch Links:

https://github.com/texane/stlink/pull/434.patch

https://github.com/texane/stlink/pull/434.diff

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#434, or mute the thread
https://github.com/notifications/unsubscribe/AAEeHz3E5Sz3hMsU-qYDgcVhIakPieS9ks5qM_-GgaJpZM4I49RN
.

xor-gate · 2016-06-18T14:37:47Z

I totaly agree, I have forgotten to update the documentation. I also will add a linux mingw build so we can see it compiles as windows target platform. I must investigate how it behaves on windows-os itself and try with app-veyor and mingw. As you know, autotools under windows is a pain in the ass. I will let you know.

texane · 2016-06-18T14:43:54Z

OK. We will wait for the merge then. Thanks for your work !

2016-06-18 16:37 GMT+02:00 Jerry Jacobs [email protected]:

I totaly agree, I have forgotten to update the documentation. I also will
add a linux mingw build so we can see it compiles as windows target
platform. I must investigate how it behaves on windows-os itself and try
with app-veyor and mingw. As you know, autotools under windows is a pain in
the ass.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#434 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAEeH63exr_BCGBSsTpveeQmXKaw_9-lks5qNAK7gaJpZM4I49RN
.

xor-gate · 2016-06-19T07:04:54Z

@texane, it took me more time then expected to integrate with AppVeyor MSYS Makefile generator project. I have it now building for 32 and 64 bit systems. I still need to update the documentation. What do you think?

Important: I would like you to activate AppVeyor integration for texane/stlink with the config file pointing to custom path: .appveyor.yml. Would you like to do this. For me it would be better to move stlink project into a separate organisation so the integrations don't impact your own account and you don't need to configure (sometimes complex) continues integration/continues deployment.

The Pro of having a separate organisation would also be when in the upcoming time I will push binary releases from Travis CI and AppVeyor CI into github/bintray we need to have deployment keys which need to configured. Also for my own stlink continues integration setup I would like to add extra code coverage output (so we know most targets, and all flash loader variants work).

Thank you for your time.
Let me know how we can continue to extent and ease the first-time user experience (and existing user base).

texane · 2016-06-19T07:27:13Z

Hi,

regarding the Windows support, let me know when the documentation is
updated and we will merge. Thanks for that !

It is good to add some support for continuous integration, but I do not
want
it to drive important decisions such as changing the project organization,
or
put constraints on the maintainers personal accounts.

2016-06-19 9:04 GMT+02:00 Jerry Jacobs [email protected]:

@texane https://github.com/texane, it took me more time then expected
to integrate with AppVeyor MSYS Makefile generator project. I have it now
building for 32 and 64 bit systems. I still need to update the
documentation. What do you think?

Important: I would like you to activate AppVeyor integration for
texane/stlink with the config file pointing to custom path: .appveyor.yml.
Would you like to do this. For me it would be better to move stlink project
into a separate organisation so the integrations don't impact your own
account and you don't need to configure (sometimes complex) continues
integration/continues deployment.

The Pro of having a separate organisation would also be when in the
upcoming time I will push binary releases from Travis CI and AppVeyor CI
into github/bintray we need to have deployment keys which need to
configured. Also for my own stlink continues integration setup I would like
to add extra code coverage output (so we know most targets, and all flash
loader variants work).

Thank you for your time.
Let me know how we can continue to extent and ease the first-time users
and existing users.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#434 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAEeH-JD0CMMDHgibk-4kOYLNpD_9Ve9ks5qNOoYgaJpZM4I49RN
.

xor-gate · 2016-06-20T15:01:46Z

@texane I have updated the build instructions and added a build helper for windows. Now we only need a MinGW64 gcc toolchain without MSYS. I have tested this myself and it compiles and runs. For some reason there are some issues with device-claim under windows (but that is a different question to fix):

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --serial
libusb: error [init_device] device '\\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
303636454646343835353530373535

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --descr
libusb: error [init_device] device '\\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
L4 device

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --flash
libusb: error [init_device] device '\\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
0xzx

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --sram
libusb: error [init_device] device '\\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
0xzx

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --probe
Found zu stlink programmers

Also the printf formatting seems to be broken. I'm using toolchain mingw-w64\x86_64-5.3.0-win32-sjlj-rt_v4-rev0. With GCC 5.3.0.

Tested with Nucleo STM32L476 (Nucleo-64) which is "mbed-enabled"

texane · 2016-06-20T18:23:42Z

Thanks !

2016-06-20 17:01 GMT+02:00 Jerry Jacobs [email protected]:

@texane https://github.com/texane I have updated the build instructions
and added a build helper for windows. Now we only need a MinGW64 gcc
toolchain without MSYS. I have tested this myself and it compiles and runs.
For some reason there are some issues with device-claim under windows (but
that is a different question to fix):

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --serial
libusb: error [init_device] device '.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
303636454646343835353530373535

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --descr
libusb: error [init_device] device '.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
L4 device

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --flash
libusb: error [init_device] device '.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
0xzx

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --sram
libusb: error [init_device] device '.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
0xzx

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --probe
Found zu stlink programmers

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#434 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAEeH550Nx1iHbA3UBYT5zP_3XDOTvQWks5qNqtbgaJpZM4I49RN
.

xor-gate · 2016-06-20T18:25:12Z

I have seen working AppVeyor and Travis with the stlink/stlink, so when this is happen to be merged and everything is in place you may disable integration for your account. Keep in mind, that no pull requests are build then so we can only check indirect when merged.

https://travis-ci.org/stlink/stlink/builds/138968255
https://ci.appveyor.com/project/stlink/stlink/build/2

texane · 2016-06-20T18:45:49Z

I will, thanks

2016-06-20 20:25 GMT+02:00 Jerry Jacobs [email protected]:

I have seen working AppVeyor and Travis with the stlink/stlink, so when
this is happen to be merged and everything is in place you may disable
integration for your account. Keep in mind, that no pull requests are build
then.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#434 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAEeH1S_oNU9fi9Tde3XOoqtq1CvOlMBks5qNtsJgaJpZM4I49RN
.

xor-gate · 2016-07-13T19:14:26Z

Some days have passed, another contributor updated the CMake files in PR #444 but first this should be merged. Then PR #444 could rebased on this.

texane · 2016-07-14T06:06:16Z

I will be on vacations for the next 2 weeks. Will take a look when coming
back.

2016-07-13 21:14 GMT+02:00 Jerry Jacobs [email protected]:

Some days have passed, another contributor updated the CMake files in PR
#444 #444 but first this should be
merged. Then PR #444 #444 could
rebased on this.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#434 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAEeHz6My-h8k56BnimDWFtSf73ph9neks5qVTkSgaJpZM4I49RN
.

xor-gate · 2016-08-03T18:12:08Z

As discussed some time ago, we will be moving away from autotools. As people get confused and makes issue solving problematic. If there are any questions with cmake or the build system, don't hesitate to open a issue new issue for further discussion.

I have merged myself as I know you sometimes are short in time, I try to make good decisions which always can be discussed beforehand.

texane · 2016-08-04T05:52:15Z

Hi Jerry,

could we take this discussion back ?

As I understand, there are 3 topics to be discussed:

. Moving away from autotools: seems OK to me, but still has
to build on all the platforms currently supported, without loss
of quality as regard with what is currently provided.

. Windows support: still has to work. Can't we just take the
currently generated MSYS Makefile and live with them ? We
do not often change these, do not have to be generated at
every pull request.

. Adding a third party service to ease the Windows build: it
does not seem justified to me, esp. regarding the impact it
has on the project or owner accounts, as discussed earlier.
So my answer to this point is definitely no.

I hope we will make some progress,

2016-08-03 20:15 GMT+02:00 Jerry Jacobs [email protected]:

As discussed some time ago, we will be moving away from autotools. As
people get confused and makes issue solving problematic. If there are any
questions with cmake or the build system, don't hesitate to open a issue
new issue for further discussion.

I have merged myself as I know you sometimes are short in time, I try to
make good decisions which always can be discussed beforehand.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#434 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEeH5TawhtKmbv2Z0dNJXcc84xzzSKdks5qcNq_gaJpZM4I49RN
.

xor-gate · 2016-08-04T07:09:31Z

I will comment on the following points:

No quality is lost, it is even enforced on multiple platforms (Linux, MinGW, Mac OS). By using multiple compilers and environments.
The windows build is working with CMake and I have put a few hour effort to make it compile again. Generating static build files and putting it aside cmake is double and will confuse people again. We are unable with static build files to compile to multiple targets: Debug (debug symbols and coverage, Release (stripped from cruft for easier distribution).
I understand, but how can you guarantee "quality/working" as mentioned in point 1 without continues integration?

texane · 2016-08-04T07:52:31Z

2016-08-04 9:09 GMT+02:00 Jerry Jacobs [email protected]:

I will comment on the following points:

No quality is lost, it is even enforced on multiple platforms
(Linux, MinGW, Mac OS). By using multiple compilers and environments.

OK

The windows build is working with CMake and I have put a few hour
effort to make it compile again. Generating static build files and putting
it aside cmake is double and will confuse people again. We are unable with
static build files to compile to multiple targets: Debug (debug symbols and
coverage, Release (stripped from cruft for easier distribution).

Just to understand: building on Windows works fine with CMake. If that is
so,
we can drop autotools then ...

I understand, but how can you guarantee "quality/working" as
mentioned in point 1 without continues integration?

As we did in the past: if the build fails on a platform, users will report
it. We
have the same problem to functionally test that a pull request wont break a
target, and it works fine.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#434 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEeHxqmVsWVhvwxvmgLxNoP79IBzlXSks5qcZAsgaJpZM4I49RN
.

xor-gate changed the title ~~Deprecate autotools and fix versioning~~ Deprecate autotools and fix versioning, build with MinGW Jun 18, 2016

xor-gate mentioned this pull request Jun 19, 2016

Further discussion about project organisation #437

Closed

xor-gate force-pushed the deprecate_autotools branch from 4ccf470 to 85b179a Compare June 20, 2016 13:49

xor-gate mentioned this pull request Jun 20, 2016

Windows MinGW64 executables have problems #438

Closed

xor-gate added this to the v2.0.0 milestone Jun 20, 2016

xor-gate added the code/refactoring label Jun 20, 2016

xor-gate mentioned this pull request Jun 29, 2016

Discussion: Autotools will be deprecated in v1.3.0 #431

Closed

This was referenced Jul 10, 2016

RFC: Build libstlink shared library, add debian packaging #444

Merged

PKG_CHECK_MODULES USB unexpected token #83

Closed

Deprecate autotools

9aac78d

xor-gate force-pushed the deprecate_autotools branch from b809473 to 9aac78d Compare August 3, 2016 18:03

xor-gate merged commit c3e208e into master Aug 3, 2016

xor-gate deleted the deprecate_autotools branch August 3, 2016 18:14

ivankravets mentioned this pull request Sep 15, 2016

Building on Windows with MinGW64 #465

Closed

Nightwalker-87 added the bug/compilation label Feb 24, 2020

Nightwalker-87 added bug/fixed status/resolved labels Feb 24, 2020

This was linked to issues Mar 17, 2020

PKG_CHECK_MODULES USB unexpected token #83

Closed

Discussion: Autotools will be deprecated in v1.3.0 #431

Closed

stlink-org locked as resolved and limited conversation to collaborators Apr 14, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Deprecate autotools and fix versioning, build with MinGW #434

Deprecate autotools and fix versioning, build with MinGW #434

xor-gate commented Jun 18, 2016

texane commented Jun 18, 2016

review-merge?

xor-gate commented Jun 18, 2016 •

edited

Loading

texane commented Jun 18, 2016

xor-gate commented Jun 19, 2016 •

edited

Loading

texane commented Jun 19, 2016

xor-gate commented Jun 20, 2016 •

edited

Loading

texane commented Jun 20, 2016

xor-gate commented Jun 20, 2016 •

edited

Loading

texane commented Jun 20, 2016

xor-gate commented Jul 13, 2016

texane commented Jul 14, 2016

xor-gate commented Aug 3, 2016 •

edited

Loading

texane commented Aug 4, 2016

xor-gate commented Aug 4, 2016

texane commented Aug 4, 2016

Deprecate autotools and fix versioning, build with MinGW #434

Deprecate autotools and fix versioning, build with MinGW #434

Conversation

xor-gate commented Jun 18, 2016

texane commented Jun 18, 2016

review-merge?

xor-gate commented Jun 18, 2016 • edited Loading

texane commented Jun 18, 2016

xor-gate commented Jun 19, 2016 • edited Loading

texane commented Jun 19, 2016

xor-gate commented Jun 20, 2016 • edited Loading

texane commented Jun 20, 2016

xor-gate commented Jun 20, 2016 • edited Loading

texane commented Jun 20, 2016

xor-gate commented Jul 13, 2016

texane commented Jul 14, 2016

xor-gate commented Aug 3, 2016 • edited Loading

texane commented Aug 4, 2016

xor-gate commented Aug 4, 2016

texane commented Aug 4, 2016

xor-gate commented Jun 18, 2016 •

edited

Loading

xor-gate commented Jun 19, 2016 •

edited

Loading

xor-gate commented Jun 20, 2016 •

edited

Loading

xor-gate commented Jun 20, 2016 •

edited

Loading

xor-gate commented Aug 3, 2016 •

edited

Loading