Path problems....

[Julen Gutierrez]

I have a problem that i dont know if i can avoid with gpasm. The compiler
doesnt work if the path is longer than 62 characters and when it contains
spaces. Can i make something? Is there any patch to fix it? It i very
important for my application. Please help me!
Thanks a lot,

Julen

[Tamas Rudnai]

I think this is related to the .COD file format unfortunately. The
documentation is not in front of me but if you can switch off the generation
of .COD files and use COFF instead then you should be fine. This is existing
on all development environment that uses .COD files, including MPASM, so
there is no other cure really than avoiding the generation of the .COD.

Alternatively you can move or create a link to your work directory so the
overall length of path become less than this 62 char limit.

Tamas


On Wed, Jul 1, 2009 at 11:10 AM, Julen Gutierrez <
j.gutierrez@...> wrote:

> I have a problem that i dont know if i can avoid with gpasm. The compiler
> doesnt work if the path is longer than 62 characters and when it contains
> spaces. Can i make something? Is there any patch to fix it? It i very
> important for my application. Please help me!
> Thanks a lot,
>
> Julen
>



--
http://www.mcuhobby.com

[Noel Henson]

That's what it is. There is the same limitation in MPLAB running under
Windows.

Noel

On Wednesday 01 July 2009, Tamas Rudnai wrote:

> I think this is related to the .COD file format unfortunately. The
> documentation is not in front of me but if you can switch off the
> generation of .COD files and use COFF instead then you should be fine.
> This is existing on all development environment that uses .COD files,
> including MPASM, so there is no other cure really than avoiding the
> generation of the .COD.
>
> Alternatively you can move or create a link to your work directory so
> the overall length of path become less than this 62 char limit.
>
> Tamas
>
>
> On Wed, Jul 1, 2009 at 11:10 AM, Julen Gutierrez <
>
> j.gutierrez@...> wrote:
> > I have a problem that i dont know if i can avoid with gpasm. The
> > compiler doesnt work if the path is longer than 62 characters and when
> > it contains spaces. Can i make something? Is there any patch to fix
> > it? It i very important for my application. Please help me!
> > Thanks a lot,
> >
> > Julen

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Julen Gutierrez-2]

Ok i know that the problem is with COD file, but i cant find any way to
avoid the creating of this file with gpasm and with gplink neither.


2009/7/1 Noel Henson <noel@...>

> That's what it is. There is the same limitation in MPLAB running under
> Windows.
>
> Noel
>
> On Wednesday 01 July 2009, Tamas Rudnai wrote:
> > I think this is related to the .COD file format unfortunately. The
> > documentation is not in front of me but if you can switch off the
> > generation of .COD files and use COFF instead then you should be fine.
> > This is existing on all development environment that uses .COD files,
> > including MPASM, so there is no other cure really than avoiding the
> > generation of the .COD.
> >
> > Alternatively you can move or create a link to your work directory so
> > the overall length of path become less than this 62 char limit.
> >
> > Tamas
> >
> >
> > On Wed, Jul 1, 2009 at 11:10 AM, Julen Gutierrez <
> >
> > j.gutierrez@...> wrote:
> > > I have a problem that i dont know if i can avoid with gpasm. The
> > > compiler doesnt work if the path is longer than 62 characters and when
> > > it contains spaces. Can i make something? Is there any patch to fix
> > > it? It i very important for my application. Please help me!
> > > Thanks a lot,
> > >
> > > Julen
>
>
>
> --
>
> ------------------------------------------------------------------
>  Noel Henson
>  www.noels-lab.com     Chips, firmware and embedded systems
>  www.vimoutliner.org   Work fast. Think well.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

[Noel Henson]

Julen,

The only practical way around this problem that I can think of is to reduce
the size of your path.  In Linux, I have all my projects in
a '~/active/client/firmware' directory.  I have had to do a similar thing
in Linux. You can also use symlinks to create a '~/firmware/project' type
of path.

Noel

On Thursday 02 July 2009, Julen Gutierrez wrote:

> Ok i know that the problem is with COD file, but i cant find any way to
> avoid the creating of this file with gpasm and with gplink neither.
>
>
> 2009/7/1 Noel Henson <noel@...>
>
> > That's what it is. There is the same limitation in MPLAB running under
> > Windows.
> >
> > Noel
> >
> > On Wednesday 01 July 2009, Tamas Rudnai wrote:
> > > I think this is related to the .COD file format unfortunately. The
> > > documentation is not in front of me but if you can switch off the
> > > generation of .COD files and use COFF instead then you should be
> > > fine. This is existing on all development environment that uses .COD
> > > files, including MPASM, so there is no other cure really than
> > > avoiding the generation of the .COD.
> > >
> > > Alternatively you can move or create a link to your work directory
> > > so the overall length of path become less than this 62 char limit.
> > >
> > > Tamas
> > >
> > >
> > > On Wed, Jul 1, 2009 at 11:10 AM, Julen Gutierrez <
> > >
> > > j.gutierrez@...> wrote:
> > > > I have a problem that i dont know if i can avoid with gpasm. The
> > > > compiler doesnt work if the path is longer than 62 characters and
> > > > when it contains spaces. Can i make something? Is there any patch
> > > > to fix it? It i very important for my application. Please help me!
> > > > Thanks a lot,
> > > >
> > > > Julen
> >
> > --
> >
> > ------------------------------------------------------------------
> >  Noel Henson
> >  www.noels-lab.com     Chips, firmware and embedded systems
> >  www.vimoutliner.org   Work fast. Think well.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > For additional commands, e-mail: gnupic-help@...

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Marko Kohtala]

gpasm has option -c to only compile coff, no cod. gplink seems to be missing
an option for it (it is implemented, just no way to activate it).

MPASM v5.30 no longer generates COD at all. There is only a separate COFF to
COD converter.

Marko

On Thu, Jul 2, 2009 at 11:06 AM, Julen Gutierrez <
j.gutierrez.bizintekinnova@...> wrote:

> Ok i know that the problem is with COD file, but i cant find any way to
> avoid the creating of this file with gpasm and with gplink neither.
>
>
> 2009/7/1 Noel Henson <noel@...>
>
> > That's what it is. There is the same limitation in MPLAB running under
> > Windows.
> >
> > Noel
> >
> > On Wednesday 01 July 2009, Tamas Rudnai wrote:
> > > I think this is related to the .COD file format unfortunately. The
> > > documentation is not in front of me but if you can switch off the
> > > generation of .COD files and use COFF instead then you should be fine.
> > > This is existing on all development environment that uses .COD files,
> > > including MPASM, so there is no other cure really than avoiding the
> > > generation of the .COD.
> > >
> > > Alternatively you can move or create a link to your work directory so
> > > the overall length of path become less than this 62 char limit.
> > >
> > > Tamas
> > >
> > >
> > > On Wed, Jul 1, 2009 at 11:10 AM, Julen Gutierrez <
> > >
> > > j.gutierrez@...> wrote:
> > > > I have a problem that i dont know if i can avoid with gpasm. The
> > > > compiler doesnt work if the path is longer than 62 characters and
> when
> > > > it contains spaces. Can i make something? Is there any patch to fix
> > > > it? It i very important for my application. Please help me!
> > > > Thanks a lot,
> > > >
> > > > Julen
> >
> >
> >
> > --
> >
> > ------------------------------------------------------------------
> >  Noel Henson
> >  www.noels-lab.com     Chips, firmware and embedded systems
> >  www.vimoutliner.org   Work fast. Think well.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > For additional commands, e-mail: gnupic-help@...
> >
> >
>

[Noel Henson]

Julen,

Another option is to change this line in libgputils/gpcod.h
#define source_len 63
to something like
#define source_len 127
and recompile.

This shouldn't hurt anything on a Linux system. But Windows can have
problems (or at least used to) with long paths.

Noel

On Thursday 02 July 2009, Julen Gutierrez wrote:

> Ok i know that the problem is with COD file, but i cant find any way to
> avoid the creating of this file with gpasm and with gplink neither.
>
>
> 2009/7/1 Noel Henson <noel@...>
>
> > That's what it is. There is the same limitation in MPLAB running under
> > Windows.
> >
> > Noel
> >
> > On Wednesday 01 July 2009, Tamas Rudnai wrote:
> > > I think this is related to the .COD file format unfortunately. The
> > > documentation is not in front of me but if you can switch off the
> > > generation of .COD files and use COFF instead then you should be
> > > fine. This is existing on all development environment that uses .COD
> > > files, including MPASM, so there is no other cure really than
> > > avoiding the generation of the .COD.
> > >
> > > Alternatively you can move or create a link to your work directory
> > > so the overall length of path become less than this 62 char limit.
> > >
> > > Tamas
> > >
> > >
> > > On Wed, Jul 1, 2009 at 11:10 AM, Julen Gutierrez <
> > >
> > > j.gutierrez@...> wrote:
> > > > I have a problem that i dont know if i can avoid with gpasm. The
> > > > compiler doesnt work if the path is longer than 62 characters and
> > > > when it contains spaces. Can i make something? Is there any patch
> > > > to fix it? It i very important for my application. Please help me!
> > > > Thanks a lot,
> > > >
> > > > Julen
> >
> > --
> >
> > ------------------------------------------------------------------
> >  Noel Henson
> >  www.noels-lab.com     Chips, firmware and embedded systems
> >  www.vimoutliner.org   Work fast. Think well.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > For additional commands, e-mail: gnupic-help@...

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Julen Gutierrez-2]

I try to use -c option and gpasm doesnt create the HEX file, just .o file.

2009/7/2 Noel Henson <noel@...>

> Julen,
>
> Another option is to change this line in libgputils/gpcod.h
> #define source_len 63
> to something like
> #define source_len 127
> and recompile.
>
> This shouldn't hurt anything on a Linux system. But Windows can have
> problems (or at least used to) with long paths.
>
> Noel
>
> On Thursday 02 July 2009, Julen Gutierrez wrote:
> > Ok i know that the problem is with COD file, but i cant find any way to
> > avoid the creating of this file with gpasm and with gplink neither.
> >
> >
> > 2009/7/1 Noel Henson <noel@...>
> >
> > > That's what it is. There is the same limitation in MPLAB running under
> > > Windows.
> > >
> > > Noel
> > >
> > > On Wednesday 01 July 2009, Tamas Rudnai wrote:
> > > > I think this is related to the .COD file format unfortunately. The
> > > > documentation is not in front of me but if you can switch off the
> > > > generation of .COD files and use COFF instead then you should be
> > > > fine. This is existing on all development environment that uses .COD
> > > > files, including MPASM, so there is no other cure really than
> > > > avoiding the generation of the .COD.
> > > >
> > > > Alternatively you can move or create a link to your work directory
> > > > so the overall length of path become less than this 62 char limit.
> > > >
> > > > Tamas
> > > >
> > > >
> > > > On Wed, Jul 1, 2009 at 11:10 AM, Julen Gutierrez <
> > > >
> > > > j.gutierrez@...> wrote:
> > > > > I have a problem that i dont know if i can avoid with gpasm. The
> > > > > compiler doesnt work if the path is longer than 62 characters and
> > > > > when it contains spaces. Can i make something? Is there any patch
> > > > > to fix it? It i very important for my application. Please help me!
> > > > > Thanks a lot,
> > > > >
> > > > > Julen
> > >
> > > --
> > >
> > > ------------------------------------------------------------------
> > >  Noel Henson
> > >  www.noels-lab.com     Chips, firmware and embedded systems
> > >  www.vimoutliner.org   Work fast. Think well.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > > For additional commands, e-mail: gnupic-help@...
>
>
>
> --
>
> ------------------------------------------------------------------
>  Noel Henson
>  www.noels-lab.com     Chips, firmware and embedded systems
>  www.vimoutliner.org   Work fast. Think well.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

[Tamas Rudnai]

That would brake the .COD fileformat so you would be incompatible with
everything.
BTW: Windows has no problem with long paths up till 4096 chars if I remember
well.

Tamas


On Thu, Jul 2, 2009 at 10:36 PM, Noel Henson <noel@...> wrote:

> Julen,
>
> Another option is to change this line in libgputils/gpcod.h
> #define source_len 63
> to something like
> #define source_len 127
> and recompile.
>
> This shouldn't hurt anything on a Linux system. But Windows can have
> problems (or at least used to) with long paths.
>
> Noel
>
> On Thursday 02 July 2009, Julen Gutierrez wrote:
> > Ok i know that the problem is with COD file, but i cant find any way to
> > avoid the creating of this file with gpasm and with gplink neither.
> >
> >
> > 2009/7/1 Noel Henson <noel@...>
> >
> > > That's what it is. There is the same limitation in MPLAB running under
> > > Windows.
> > >
> > > Noel
> > >
> > > On Wednesday 01 July 2009, Tamas Rudnai wrote:
> > > > I think this is related to the .COD file format unfortunately. The
> > > > documentation is not in front of me but if you can switch off the
> > > > generation of .COD files and use COFF instead then you should be
> > > > fine. This is existing on all development environment that uses .COD
> > > > files, including MPASM, so there is no other cure really than
> > > > avoiding the generation of the .COD.
> > > >
> > > > Alternatively you can move or create a link to your work directory
> > > > so the overall length of path become less than this 62 char limit.
> > > >
> > > > Tamas
> > > >
> > > >
> > > > On Wed, Jul 1, 2009 at 11:10 AM, Julen Gutierrez <
> > > >
> > > > j.gutierrez@...> wrote:
> > > > > I have a problem that i dont know if i can avoid with gpasm. The
> > > > > compiler doesnt work if the path is longer than 62 characters and
> > > > > when it contains spaces. Can i make something? Is there any patch
> > > > > to fix it? It i very important for my application. Please help me!
> > > > > Thanks a lot,
> > > > >
> > > > > Julen
> > >
> > > --
> > >
> > > ------------------------------------------------------------------
> > >  Noel Henson
> > >  www.noels-lab.com     Chips, firmware and embedded systems
> > >  www.vimoutliner.org   Work fast. Think well.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > > For additional commands, e-mail: gnupic-help@...
>
>
>
> --
>
> ------------------------------------------------------------------
>  Noel Henson
>  www.noels-lab.com     Chips, firmware and embedded systems
>  www.vimoutliner.org   Work fast. Think well.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

--
http://www.mcuhobby.com

[Peter Restall]

On Fri, 3 Jul 2009 08:11:02 +0100, Tamas Rudnai wrote:

> That would brake the .COD fileformat so you would be incompatible with
> everything.
> BTW: Windows has no problem with long paths up till 4096 chars if I remember
> well.
>
> Tamas

There is also what they call a 'junction' in Windows; it's basically their
version of a symlink.  If the OP is using a Windows machine then he may wish
to continue with his code in the original directory and possibly create a
junction to it with a shorter name, and do the compilations, etc. from there
as was suggested in relation to Linux a few messages ago.

The downside is that you need a program from MS to create junctions (it's part
of the Win32 API but a program to utilise it is not included by default IIRC),
and I forget what it's called; it's part of the server tools package I think.
Just do a google and it'll pop up.

Regards,

Pete Restall

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Noel Henson]

Yes, it would brake the COD files but if they're not being used, it
shouldn't matter.

For modern Windows, you are correct. But MPLAB has a loooong history. I've
been using it for a very long time. I believe I first used it under Windows
95 but I designed in and programmed my first PIC in 1989.  

Anyway, for whatever reason there is a hard-coded limit to the length of
the source filename.  It is limited to 62 + a null for termination. It
couldn't take much time to recompile it.

Noel

On Friday 03 July 2009, Tamas Rudnai wrote:

> That would brake the .COD fileformat so you would be incompatible with
> everything.
> BTW: Windows has no problem with long paths up till 4096 chars if I
> remember well.
>
> Tamas
>
> On Thu, Jul 2, 2009 at 10:36 PM, Noel Henson <noel@...> wrote:
> > Julen,
> >
> > Another option is to change this line in libgputils/gpcod.h
> > #define source_len 63
> > to something like
> > #define source_len 127
> > and recompile.
> >
> > This shouldn't hurt anything on a Linux system. But Windows can have
> > problems (or at least used to) with long paths.
> >
> > Noel
> >
> > On Thursday 02 July 2009, Julen Gutierrez wrote:
> > > Ok i know that the problem is with COD file, but i cant find any way
> > > to avoid the creating of this file with gpasm and with gplink
> > > neither.
> > >
> > >
> > > 2009/7/1 Noel Henson <noel@...>
> > >
> > > > That's what it is. There is the same limitation in MPLAB running
> > > > under Windows.
> > > >
> > > > Noel
> > > >
> > > > On Wednesday 01 July 2009, Tamas Rudnai wrote:
> > > > > I think this is related to the .COD file format unfortunately.
> > > > > The documentation is not in front of me but if you can switch
> > > > > off the generation of .COD files and use COFF instead then you
> > > > > should be fine. This is existing on all development environment
> > > > > that uses .COD files, including MPASM, so there is no other cure
> > > > > really than avoiding the generation of the .COD.
> > > > >
> > > > > Alternatively you can move or create a link to your work
> > > > > directory so the overall length of path become less than this 62
> > > > > char limit.
> > > > >
> > > > > Tamas
> > > > >
> > > > >
> > > > > On Wed, Jul 1, 2009 at 11:10 AM, Julen Gutierrez <
> > > > >
> > > > > j.gutierrez@...> wrote:
> > > > > > I have a problem that i dont know if i can avoid with gpasm.
> > > > > > The compiler doesnt work if the path is longer than 62
> > > > > > characters and when it contains spaces. Can i make something?
> > > > > > Is there any patch to fix it? It i very important for my
> > > > > > application. Please help me! Thanks a lot,
> > > > > >
> > > > > > Julen
> > > >
> > > > --
> > > >
> > > > ------------------------------------------------------------------
> > > >  Noel Henson
> > > >  www.noels-lab.com     Chips, firmware and embedded systems
> > > >  www.vimoutliner.org   Work fast. Think well.
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > >--- To unsubscribe, e-mail: gnupic-unsubscribe@... For
> > > > additional commands, e-mail: gnupic-help@...
> >
> > --
> >
> > ------------------------------------------------------------------
> >  Noel Henson
> >  www.noels-lab.com     Chips, firmware and embedded systems
> >  www.vimoutliner.org   Work fast. Think well.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > For additional commands, e-mail: gnupic-help@...

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Marko Kohtala]

If these .COD files are not needed for anything, why not just disable the
generation of them? Microchip dropped them completely to fix these same
problems.

You need to go to gpasm/gpasm.c and gplink/gplink.c and change
  state.codfile = normal;
to
  state.codfile = suppress;

Of course, a better patch would also add an option to enable the .COD output
for those who need it.

(I did not test this, feel free to create and test the patch.)

Marko

On Fri, Jul 3, 2009 at 10:59 AM, Noel Henson <noel@...> wrote:

> Yes, it would brake the COD files but if they're not being used, it
> shouldn't matter.
>
> For modern Windows, you are correct. But MPLAB has a loooong history. I've
> been using it for a very long time. I believe I first used it under Windows
> 95 but I designed in and programmed my first PIC in 1989.
>
> Anyway, for whatever reason there is a hard-coded limit to the length of
> the source filename.  It is limited to 62 + a null for termination. It
> couldn't take much time to recompile it.
>
> Noel
>
> On Friday 03 July 2009, Tamas Rudnai wrote:
> > That would brake the .COD fileformat so you would be incompatible with
> > everything.
> > BTW: Windows has no problem with long paths up till 4096 chars if I
> > remember well.
> >
> > Tamas
> >
> > On Thu, Jul 2, 2009 at 10:36 PM, Noel Henson <noel@...> wrote:
> > > Julen,
> > >
> > > Another option is to change this line in libgputils/gpcod.h
> > > #define source_len 63
> > > to something like
> > > #define source_len 127
> > > and recompile.
> > >
> > > This shouldn't hurt anything on a Linux system. But Windows can have
> > > problems (or at least used to) with long paths.
> > >
> > > Noel
> > >
> > > On Thursday 02 July 2009, Julen Gutierrez wrote:
> > > > Ok i know that the problem is with COD file, but i cant find any way
> > > > to avoid the creating of this file with gpasm and with gplink
> > > > neither.
> > > >
> > > >
> > > > 2009/7/1 Noel Henson <noel@...>
> > > >
> > > > > That's what it is. There is the same limitation in MPLAB running
> > > > > under Windows.
> > > > >
> > > > > Noel
> > > > >
> > > > > On Wednesday 01 July 2009, Tamas Rudnai wrote:
> > > > > > I think this is related to the .COD file format unfortunately.
> > > > > > The documentation is not in front of me but if you can switch
> > > > > > off the generation of .COD files and use COFF instead then you
> > > > > > should be fine. This is existing on all development environment
> > > > > > that uses .COD files, including MPASM, so there is no other cure
> > > > > > really than avoiding the generation of the .COD.
> > > > > >
> > > > > > Alternatively you can move or create a link to your work
> > > > > > directory so the overall length of path become less than this 62
> > > > > > char limit.
> > > > > >
> > > > > > Tamas
> > > > > >
> > > > > >
> > > > > > On Wed, Jul 1, 2009 at 11:10 AM, Julen Gutierrez <
> > > > > >
> > > > > > j.gutierrez@...> wrote:
> > > > > > > I have a problem that i dont know if i can avoid with gpasm.
> > > > > > > The compiler doesnt work if the path is longer than 62
> > > > > > > characters and when it contains spaces. Can i make something?
> > > > > > > Is there any patch to fix it? It i very important for my
> > > > > > > application. Please help me! Thanks a lot,
> > > > > > >
> > > > > > > Julen
> > > > >
> > > > > --
> > > > >
> > > > > ------------------------------------------------------------------
> > > > >  Noel Henson
> > > > >  www.noels-lab.com     Chips, firmware and embedded systems
> > > > >  www.vimoutliner.org   Work fast. Think well.
> > > > >
> > > > >
> > > > > ------------------------------------------------------------------
> > > > >--- To unsubscribe, e-mail: gnupic-unsubscribe@... For
> > > > > additional commands, e-mail: gnupic-help@...
> > >
> > > --
> > >
> > > ------------------------------------------------------------------
> > >  Noel Henson
> > >  www.noels-lab.com     Chips, firmware and embedded systems
> > >  www.vimoutliner.org   Work fast. Think well.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > > For additional commands, e-mail: gnupic-help@...
>
>
>
> --
>
> ------------------------------------------------------------------
>  Noel Henson
>  www.noels-lab.com     Chips, firmware and embedded systems
>  www.vimoutliner.org   Work fast. Think well.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

[Xiaofan Chen]

On Fri, Jul 3, 2009 at 3:11 PM, Tamas Rudnai<tamas.rudnai@...> wrote:
> That would brake the .COD fileformat so you would be incompatible with
> everything.

Why? MPLAB no longer uses .cod file. Only some 3rd party tools
are using .cod file.

As mentioned by Marko, latest MASM no longer generates .cod file
to avoid this issue.

--
Xiaofan http://mcuee.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Julen Gutierrez-2]

Actually now i am able to compile my projects without problem....
my application is a robotic graphic compiler writen in C# and i use gpasm.

If i create a cmd window and write on it the gpasm with the long path it
works...



2009/7/3 Marko Kohtala <marko.kohtala@...>

> If these .COD files are not needed for anything, why not just disable the
> generation of them? Microchip dropped them completely to fix these same
> problems.
>
> You need to go to gpasm/gpasm.c and gplink/gplink.c and change
>  state.codfile = normal;
> to
>  state.codfile = suppress;
>
> Of course, a better patch would also add an option to enable the .COD
> output
> for those who need it.
>
> (I did not test this, feel free to create and test the patch.)
>
> Marko
>
> On Fri, Jul 3, 2009 at 10:59 AM, Noel Henson <noel@...> wrote:
>
> > Yes, it would brake the COD files but if they're not being used, it
> > shouldn't matter.
> >
> > For modern Windows, you are correct. But MPLAB has a loooong history.
> I've
> > been using it for a very long time. I believe I first used it under
> Windows
> > 95 but I designed in and programmed my first PIC in 1989.
> >
> > Anyway, for whatever reason there is a hard-coded limit to the length of
> > the source filename.  It is limited to 62 + a null for termination. It
> > couldn't take much time to recompile it.
> >
> > Noel
> >
> > On Friday 03 July 2009, Tamas Rudnai wrote:
> > > That would brake the .COD fileformat so you would be incompatible with
> > > everything.
> > > BTW: Windows has no problem with long paths up till 4096 chars if I
> > > remember well.
> > >
> > > Tamas
> > >
> > > On Thu, Jul 2, 2009 at 10:36 PM, Noel Henson <noel@...>
> wrote:
> > > > Julen,
> > > >
> > > > Another option is to change this line in libgputils/gpcod.h
> > > > #define source_len 63
> > > > to something like
> > > > #define source_len 127
> > > > and recompile.
> > > >
> > > > This shouldn't hurt anything on a Linux system. But Windows can have
> > > > problems (or at least used to) with long paths.
> > > >
> > > > Noel
> > > >
> > > > On Thursday 02 July 2009, Julen Gutierrez wrote:
> > > > > Ok i know that the problem is with COD file, but i cant find any
> way
> > > > > to avoid the creating of this file with gpasm and with gplink
> > > > > neither.
> > > > >
> > > > >
> > > > > 2009/7/1 Noel Henson <noel@...>
> > > > >
> > > > > > That's what it is. There is the same limitation in MPLAB running
> > > > > > under Windows.
> > > > > >
> > > > > > Noel
> > > > > >
> > > > > > On Wednesday 01 July 2009, Tamas Rudnai wrote:
> > > > > > > I think this is related to the .COD file format unfortunately.
> > > > > > > The documentation is not in front of me but if you can switch
> > > > > > > off the generation of .COD files and use COFF instead then you
> > > > > > > should be fine. This is existing on all development environment
> > > > > > > that uses .COD files, including MPASM, so there is no other
> cure
> > > > > > > really than avoiding the generation of the .COD.
> > > > > > >
> > > > > > > Alternatively you can move or create a link to your work
> > > > > > > directory so the overall length of path become less than this
> 62
> > > > > > > char limit.
> > > > > > >
> > > > > > > Tamas
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Jul 1, 2009 at 11:10 AM, Julen Gutierrez <
> > > > > > >
> > > > > > > j.gutierrez@...> wrote:
> > > > > > > > I have a problem that i dont know if i can avoid with gpasm.
> > > > > > > > The compiler doesnt work if the path is longer than 62
> > > > > > > > characters and when it contains spaces. Can i make something?
> > > > > > > > Is there any patch to fix it? It i very important for my
> > > > > > > > application. Please help me! Thanks a lot,
> > > > > > > >
> > > > > > > > Julen
> > > > > >
> > > > > > --
> > > > > >
> > > > > >
> ------------------------------------------------------------------
> > > > > >  Noel Henson
> > > > > >  www.noels-lab.com     Chips, firmware and embedded systems
> > > > > >  www.vimoutliner.org   Work fast. Think well.
> > > > > >
> > > > > >
> > > > > >
> ------------------------------------------------------------------
> > > > > >--- To unsubscribe, e-mail: gnupic-unsubscribe@...
> > > > > > additional commands, e-mail: gnupic-help@...
> > > >
> > > > --
> > > >
> > > > ------------------------------------------------------------------
> > > >  Noel Henson
> > > >  www.noels-lab.com     Chips, firmware and embedded systems
> > > >  www.vimoutliner.org   Work fast. Think well.
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > > > For additional commands, e-mail: gnupic-help@...
> >
> >
> >
> > --
> >
> > ------------------------------------------------------------------
> >  Noel Henson
> >  www.noels-lab.com     Chips, firmware and embedded systems
> >  www.vimoutliner.org   Work fast. Think well.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > For additional commands, e-mail: gnupic-help@...
> >
> >
>

[Xiaofan Chen]

On Fri, Jul 3, 2009 at 3:59 PM, Noel Henson<noel@...> wrote:
> Anyway, for whatever reason there is a hard-coded limit to the length of
> the source filename.  It is limited to 62 + a null for termination. It
> couldn't take much time to recompile it.
>

This is the limit of .cod file formats. You can not do anything about
it since it is controlled by Byte Craft. You can request the spec
about .cod file format.

http://www.bytecraft.com/more_info/codfile_request
http://osdir.com/ml/hardware.microcontrollers.gnupic/2007-04/msg00011.html

--
Xiaofan http://mcuee.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Tamas Rudnai]

On a Windows machine you can substitute a path to a drive letter so the end
you will have a shorter path:

C:\> SUBST X: "C:\Documents and Settings\myUserName\My
Documents\Projects\PIC\myCurrentProject"

...now you can access to your directory with X: drive ....

Tamas


On Fri, Jul 3, 2009 at 8:50 AM, Peter Restall <pete@...> wrote:

>
> On Fri, 3 Jul 2009 08:11:02 +0100, Tamas Rudnai wrote:
>
> > That would brake the .COD fileformat so you would be incompatible with
> > everything.
> > BTW: Windows has no problem with long paths up till 4096 chars if I
> remember
> > well.
> >
> > Tamas
>
> There is also what they call a 'junction' in Windows; it's basically their
> version of a symlink.  If the OP is using a Windows machine then he may
> wish
> to continue with his code in the original directory and possibly create a
> junction to it with a shorter name, and do the compilations, etc. from
> there
> as was suggested in relation to Linux a few messages ago.
>
> The downside is that you need a program from MS to create junctions (it's
> part
> of the Win32 API but a program to utilise it is not included by default
> IIRC),
> and I forget what it's called; it's part of the server tools package I
> think.
> Just do a google and it'll pop up.
>
> Regards,
>
> Pete Restall
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

--
http://www.mcuhobby.com

[Julen Gutierrez-2]

I didnt know that... interesting but anyway why does it working now?
It could be very interesting for next version that the generation of cod
file would be optional.

Thanks all!!!!!!

2009/7/3 Tamas Rudnai <tamas.rudnai@...>

> On a Windows machine you can substitute a path to a drive letter so the end
> you will have a shorter path:
>
> C:\> SUBST X: "C:\Documents and Settings\myUserName\My
> Documents\Projects\PIC\myCurrentProject"
>
> ...now you can access to your directory with X: drive ....
>
> Tamas
>
>
> On Fri, Jul 3, 2009 at 8:50 AM, Peter Restall <pete@...> wrote:
>
> >
> > On Fri, 3 Jul 2009 08:11:02 +0100, Tamas Rudnai wrote:
> >
> > > That would brake the .COD fileformat so you would be incompatible with
> > > everything.
> > > BTW: Windows has no problem with long paths up till 4096 chars if I
> > remember
> > > well.
> > >
> > > Tamas
> >
> > There is also what they call a 'junction' in Windows; it's basically
> their
> > version of a symlink.  If the OP is using a Windows machine then he may
> > wish
> > to continue with his code in the original directory and possibly create a
> > junction to it with a shorter name, and do the compilations, etc. from
> > there
> > as was suggested in relation to Linux a few messages ago.
> >
> > The downside is that you need a program from MS to create junctions (it's
> > part
> > of the Win32 API but a program to utilise it is not included by default
> > IIRC),
> > and I forget what it's called; it's part of the server tools package I
> > think.
> > Just do a google and it'll pop up.
> >
> > Regards,
> >
> > Pete Restall
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > For additional commands, e-mail: gnupic-help@...
> >
> >
>
>
> --
> http://www.mcuhobby.com
>

[Peter Restall]

On Fri, 3 Jul 2009 09:16:40 +0100, Tamas Rudnai wrote:

> On a Windows machine you can substitute a path to a drive letter so the end
> you will have a shorter path:
>
> C:\> SUBST X: "C:\Documents and Settings\myUserName\My
> Documents\Projects\PIC\myCurrentProject"
>
> ...now you can access to your directory with X: drive ....
>
> Tamas

I can't believe I didn't think of that !  The subst util has been around since
the bad (good ?) old days of MS-DOS; and I used to use it all the time, honest
'guv :)

Cheers,

Pete Restall

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Noel Henson]

I just downloaded 0.13.7 and reviewed the sources. It appears that the -c
option will now suppress the creation of the COD files. It looks like no
patch is necessary.

Noel

On Friday 03 July 2009, Julen Gutierrez wrote:

> Actually now i am able to compile my projects without problem....
> my application is a robotic graphic compiler writen in C# and i use
> gpasm.
>
> If i create a cmd window and write on it the gpasm with the long path it
> works...
>
>
>
> 2009/7/3 Marko Kohtala <marko.kohtala@...>
>
> > If these .COD files are not needed for anything, why not just disable
> > the generation of them? Microchip dropped them completely to fix these
> > same problems.
> >
> > You need to go to gpasm/gpasm.c and gplink/gplink.c and change
> >  state.codfile = normal;
> > to
> >  state.codfile = suppress;
> >
> > Of course, a better patch would also add an option to enable the .COD
> > output
> > for those who need it.
> >
> > (I did not test this, feel free to create and test the patch.)
> >
> > Marko
> >
> > On Fri, Jul 3, 2009 at 10:59 AM, Noel Henson <noel@...>

wrote:

> > > Yes, it would brake the COD files but if they're not being used, it
> > > shouldn't matter.
> > >
> > > For modern Windows, you are correct. But MPLAB has a loooong
> > > history.
> >
> > I've
> >
> > > been using it for a very long time. I believe I first used it under
> >
> > Windows
> >
> > > 95 but I designed in and programmed my first PIC in 1989.
> > >
> > > Anyway, for whatever reason there is a hard-coded limit to the
> > > length of the source filename.  It is limited to 62 + a null for
> > > termination. It couldn't take much time to recompile it.
> > >
> > > Noel
> > >
> > > On Friday 03 July 2009, Tamas Rudnai wrote:
> > > > That would brake the .COD fileformat so you would be incompatible
> > > > with everything.
> > > > BTW: Windows has no problem with long paths up till 4096 chars if
> > > > I remember well.
> > > >
> > > > Tamas
> > > >
> > > > On Thu, Jul 2, 2009 at 10:36 PM, Noel Henson <noel@...>
> >
> > wrote:
> > > > > Julen,
> > > > >
> > > > > Another option is to change this line in libgputils/gpcod.h
> > > > > #define source_len 63
> > > > > to something like
> > > > > #define source_len 127
> > > > > and recompile.
> > > > >
> > > > > This shouldn't hurt anything on a Linux system. But Windows can
> > > > > have problems (or at least used to) with long paths.
> > > > >
> > > > > Noel
> > > > >
> > > > > On Thursday 02 July 2009, Julen Gutierrez wrote:
> > > > > > Ok i know that the problem is with COD file, but i cant find
> > > > > > any
> >
> > way
> >
> > > > > > to avoid the creating of this file with gpasm and with gplink
> > > > > > neither.
> > > > > >
> > > > > >
> > > > > > 2009/7/1 Noel Henson <noel@...>
> > > > > >
> > > > > > > That's what it is. There is the same limitation in MPLAB
> > > > > > > running under Windows.
> > > > > > >
> > > > > > > Noel
> > > > > > >
> > > > > > > On Wednesday 01 July 2009, Tamas Rudnai wrote:
> > > > > > > > I think this is related to the .COD file format
> > > > > > > > unfortunately. The documentation is not in front of me but
> > > > > > > > if you can switch off the generation of .COD files and use
> > > > > > > > COFF instead then you should be fine. This is existing on
> > > > > > > > all development environment that uses .COD files,
> > > > > > > > including MPASM, so there is no other
> >
> > cure
> >
> > > > > > > > really than avoiding the generation of the .COD.
> > > > > > > >
> > > > > > > > Alternatively you can move or create a link to your work
> > > > > > > > directory so the overall length of path become less than
> > > > > > > > this
> >
> > 62
> >
> > > > > > > > char limit.
> > > > > > > >
> > > > > > > > Tamas
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Jul 1, 2009 at 11:10 AM, Julen Gutierrez <
> > > > > > > >
> > > > > > > > j.gutierrez@...> wrote:
> > > > > > > > > I have a problem that i dont know if i can avoid with
> > > > > > > > > gpasm. The compiler doesnt work if the path is longer
> > > > > > > > > than 62 characters and when it contains spaces. Can i
> > > > > > > > > make something? Is there any patch to fix it? It i very
> > > > > > > > > important for my application. Please help me! Thanks a
> > > > > > > > > lot,
> > > > > > > > >
> > > > > > > > > Julen
> > > > > > >
> > > > > > > --
> >
> > ------------------------------------------------------------------
> >
> > > > > > >  Noel Henson
> > > > > > >  www.noels-lab.com     Chips, firmware and embedded systems
> > > > > > >  www.vimoutliner.org   Work fast. Think well.
> >
> > ------------------------------------------------------------------
> >
> > > > > > >--- To unsubscribe, e-mail:
> > > > > > > gnupic-unsubscribe@... additional commands,
> > > > > > > e-mail: gnupic-help@...
> > > > >
> > > > > --
> > > > >
> > > > > ----------------------------------------------------------------
> > > > >-- Noel Henson
> > > > >  www.noels-lab.com     Chips, firmware and embedded systems
> > > > >  www.vimoutliner.org   Work fast. Think well.
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > >----- To unsubscribe, e-mail: gnupic-unsubscribe@...
> > > > > For additional commands, e-mail: gnupic-help@...
> > >
> > > --
> > >
> > > ------------------------------------------------------------------
> > >  Noel Henson
> > >  www.noels-lab.com     Chips, firmware and embedded systems
> > >  www.vimoutliner.org   Work fast. Think well.
> > >
> > >
> > > --------------------------------------------------------------------
> > >- To unsubscribe, e-mail: gnupic-unsubscribe@...
> > > For additional commands, e-mail: gnupic-help@...

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...