On 28/06/2011 10:09, Steve Bennett wrote:
One observation is that jimsh0 is built in the src dir, perhaps it
would be better to use the builddir.
I tend to build out of tree for various arch's and having jimsh0 built
in the src dir does create issues for this kind of setup.
I will see if this
On 28/06/2011, at 6:32 PM, Spencer Oliver wrote:
> On 27 June 2011 22:33, Steve Bennett wrote:
> On 27/06/2011, at 10:07 PM, Spencer Oliver wrote:
>
>> On 27 June 2011 11:05, Spencer Oliver wrote:
>> Thanks that solves all the problems i see with make distcheck.
>> At some point i may look into
On 28/06/2011, at 6:24 PM, Spencer Oliver wrote:
> On 27 June 2011 22:33, Steve Bennett wrote:
> On 27/06/2011, at 10:07 PM, Spencer Oliver wrote:
>
>> On 27 June 2011 11:05, Spencer Oliver wrote:
>> Thanks that solves all the problems i see with make distcheck.
>> At some point i may look into
On 27 June 2011 22:33, Steve Bennett wrote:
> On 27/06/2011, at 10:07 PM, Spencer Oliver wrote:
>
> On 27 June 2011 11:05, Spencer Oliver wrote:
>
>> Thanks that solves all the problems i see with make distcheck.
>> At some point i may look into a method of tweaking so we do not install
>> unnec
On 27 June 2011 22:33, Steve Bennett wrote:
> On 27/06/2011, at 10:07 PM, Spencer Oliver wrote:
>
> On 27 June 2011 11:05, Spencer Oliver wrote:
>
>> Thanks that solves all the problems i see with make distcheck.
>> At some point i may look into a method of tweaking so we do not install
>> unnec
> Try latest git. You will need to remove the old autosetup/jimsh0.exe
It's a good idea to run 'git clean -f -d -x' prior to running
autotools and friends. This will erase all files and directories that
aren't under revision control.
Regards,
Dimitar
___
On 27/06/2011, at 10:07 PM, Spencer Oliver wrote:
> On 27 June 2011 11:05, Spencer Oliver wrote:
> Thanks that solves all the problems i see with make distcheck.
> At some point i may look into a method of tweaking so we do not install
> unnecessary files, but all is good for the next openocd re
On 27/06/2011, at 10:07 PM, Spencer Oliver wrote:
> On 27 June 2011 11:05, Spencer Oliver wrote:
> Thanks that solves all the problems i see with make distcheck.
> At some point i may look into a method of tweaking so we do not install
> unnecessary files, but all is good for the next openocd re
On 27 June 2011 11:05, Spencer Oliver wrote:
> Thanks that solves all the problems i see with make distcheck.
> At some point i may look into a method of tweaking so we do not install
> unnecessary files, but all is good for the next openocd release.
>
> Cheers
> Spen
>
Spoke to soon :)
jimtcl h
On 21 June 2011 07:44, Spencer Oliver wrote:
> >
> > Try this:
> http://repo.or.cz/w/jimtcl.git/commit/fbc998db178da5c462e164b63da128a7d7412e37
> >
> > With your recent changes, now 'make distcheck' works for me.
> >
>
> Many thanks :-)
>
> I am away on holiday at the moment so will not get time
>
> Try this:
http://repo.or.cz/w/jimtcl.git/commit/fbc998db178da5c462e164b63da128a7d7412e37
>
> With your recent changes, now 'make distcheck' works for me.
>
Many thanks :-)
I am away on holiday at the moment so will not get time to look at this
again until next week.
Cheers
Spen
_
On 19/06/2011, at 4:59 PM, Steve Bennett wrote:
> On 17/06/2011, at 6:51 PM, Spencer Oliver wrote:
>
>> On 17 June 2011 01:11, Steve Bennett wrote:
>>
>> Yes, you're right. Try the attached patch.
>>
>> make distcheck mostly works for me, but the build fails for reasons which is
>> nothing
>>
On 17/06/2011, at 6:51 PM, Spencer Oliver wrote:
> On 17 June 2011 01:11, Steve Bennett wrote:
>
> Yes, you're right. Try the attached patch.
>
> make distcheck mostly works for me, but the build fails for reasons which is
> nothing
> to do with jimtcl. Not sure if there are any more problems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Spencer Oliver scrisse:
> The solution as mentioned is to either get the user to download jim
> and install in the jimtcl dir of openocd or we tweak jim to work with
> make dist. I have been making a few tweaks and got it working, but it
> is a bodge
On 16 June 2011 13:02, Steve Bennett wrote:
> Hmmm. Works for me. Can you send me first few lines of git log in the
> jimtcl dir and also the output of make distcheck? And also jimtcl/Makefile
>
> Cheers,
> Steve
>
I think there is some confusion again.
openocd and jimtcl build ok - even after u
Hmmm. Works for me. Can you send me first few lines of git log in the jimtcl
dir and also the output of make distcheck? And also jimtcl/Makefile
Cheers,
Steve
On 16/06/2011, at 6:33 PM, Spencer Oliver wrote:
> On 16 June 2011 05:38, Steve Bennett wrote:
> On 16/06/2011, at 7:49 AM, Spencer Ol
On 16 June 2011 05:38, Steve Bennett wrote:
> On 16/06/2011, at 7:49 AM, Spencer Oliver wrote:
>
>
> On Jun 15, 2011 10:30 PM, "Øyvind Harboe" wrote:
> >
> > I think we should stick to distributing source packages only.
> >
>
> That's my plan
> - even that is not easy as Jim does not use autocon
On 16/06/2011, at 7:49 AM, Spencer Oliver wrote:
>
> On Jun 15, 2011 10:30 PM, "Øyvind Harboe" wrote:
> >
> > I think we should stick to distributing source packages only.
> >
>
> That's my plan
> - even that is not easy as Jim does not use autoconf etc.
>
>
That sounds like an easy problem
On Jun 15, 2011 10:30 PM, "Øyvind Harboe" wrote:
>
> I think we should stick to distributing source packages only.
>
That's my plan
- even that is not easy as Jim does not use autoconf etc.
Cheers
Spen
___
Openocd-development mailing list
Openocd-devel
On Wed, Jun 15, 2011 at 9:30 PM, Øyvind Harboe wrote:
> I think we should stick to distributing source packages only.
>
> For the source package, we can include the version of Jim Tcl we
> tested with.
>
> If someone wants something else, they can start with cloning
> the openocd repository and ch
I think we should stick to distributing source packages only.
For the source package, we can include the version of Jim Tcl we
tested with.
If someone wants something else, they can start with cloning
the openocd repository and checking out the release tag?
--
Øyvind Harboe
Can Zylin Consulti
On Jun 15, 2011 10:10 PM, "Tomek CEDRO" wrote:
>
> Hello Spencer :-)
>
> I would use git submodule and simply include JimTCL with OpenOCD build
> binary. This would save lots of problems and produce common
> distribution. Anyone who want to use external library can build
> his/her own binary. Ofco
Hello Spencer :-)
I would use git submodule and simply include JimTCL with OpenOCD build
binary. This would save lots of problems and produce common
distribution. Anyone who want to use external library can build
his/her own binary. Ofcourse there is a situation to solve what to to
when JimTCL is
On Jun 15, 2011 8:08 PM, "Øyvind Harboe" wrote:
>
> On Wed, Jun 15, 2011 at 9:01 PM, Spencer Oliver
wrote:
> > The main thing that needs fixing is the issue with how to release the
Jim
> > tcl lib.
> > Currently a make distcheck will fail due the Jim lib.
> >
> > Previously Jim was integrated and
On Wed, Jun 15, 2011 at 9:01 PM, Spencer Oliver wrote:
> The main thing that needs fixing is the issue with how to release the Jim
> tcl lib.
> Currently a make distcheck will fail due the Jim lib.
>
> Previously Jim was integrated and this made releases simpler - now we have
> to decide whether t
The main thing that needs fixing is the issue with how to release the Jim
tcl lib.
Currently a make distcheck will fail due the Jim lib.
Previously Jim was integrated and this made releases simpler - now we have
to decide whether to leave it seperate or release the Jim src with openocd
release pac
>
> It is common practice for an open-source project to release a
> version as a tar of the source code. I expect we will
> release a source code tar, linux binaries, and win32 binaries.
>
That's my thinking.
Spen
___
Openocd-development mailing
On Nov 25, 2008, at 1:19 PM, Steve Franks wrote:
we are not guessing, we are creating a release branch that will be
as such
frozen except for major bug fixes.
if after testing (month or so) all is good then we tag a release 1.0.
Might I also suggest that 1.0 be available to download as a .t
> we are not guessing, we are creating a release branch that will be as such
> frozen except for major bug fixes.
> if after testing (month or so) all is good then we tag a release 1.0.
Might I also suggest that 1.0 be available to download as a .tgz or
simliar file? Most of the automated package
> > Any objections/comments?
>
> Instead of trying to *guess* when is a good time to cut a
> branch, lets just pick a version everybody is happy with and
> work from that.
>
we are not guessing, we are creating a release branch that will be as such
frozen except for major bug fixes.
if after t
On Mon, Nov 24, 2008 at 11:51 AM, Spen <[EMAIL PROTECTED]> wrote:
>> > Any objections/comments?
>>
>> Instead of trying to *guess* when is a good time to cut a
>> branch, lets just pick a version everybody is happy with and
>> work from that.
>>
>
> we are not guessing, we are creating a release br
On Nov 23, 2008, at 9:27 AM, Øyvind Harboe wrote:
On Sat, Nov 22, 2008 at 12:54 PM, Spen <[EMAIL PROTECTED]> wrote:
Hi,
I think its about time openocd made a release 1.0.
I propose we create a openocd_rel_1_0 branch that will be frozen
(except for
major bugs) after a month we make a releas
On Sat, Nov 22, 2008 at 12:54 PM, Spen <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I think its about time openocd made a release 1.0.
> I propose we create a openocd_rel_1_0 branch that will be frozen (except for
> major bugs) after a month we make a release.
>
> Any objections/comments?
Instead of tryin
Spen wrote:
> Hi,
>
> I think its about time openocd made a release 1.0.
> I propose we create a openocd_rel_1_0 branch that will be frozen (except for
> major bugs) after a month we make a release.
>
> Any objections/comments?
It would be good to gather a list of devices which will be tested /
On Nov 22, 2008, at 3:54 AM, Spen wrote:
Hi,
I think its about time openocd made a release 1.0.
I propose we create a openocd_rel_1_0 branch that will be frozen
(except for
major bugs) after a month we make a release.
Any objections/comments?
release will be for both x86 win32 (mingw) and
> spen> release will be for both x86 win32 (mingw) and linux
>
> I would add a Cygwin build.
>
> Only because - often some development environments are
> _cygwin_ in addition to mingw
>
Fair enough - easily done.
Spen
___
Openocd-development mailin
spen> release will be for both x86 win32 (mingw) and linux
I would add a Cygwin build.
Only because - often some development environments are _cygwin_ in
addition to mingw
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.
Hi,
I think its about time openocd made a release 1.0.
I propose we create a openocd_rel_1_0 branch that will be frozen (except for
major bugs) after a month we make a release.
Any objections/comments?
release will be for both x86 win32 (mingw) and linux
suggested build options will be (win32):
38 matches
Mail list logo
