Ensure that the new INCLUDE feature works with releative paths

[hobu]

I don't think anyone has tested this, and I know the buildkit has probably not
had its lexer and parser .c files updated to try this out.  We should verify
that this is working with the buildkit stuff and there are no funky windows
issues (text/binary reading of streams etc).

Put it here in a bug so at least we don't forget

[jmckenna@…]

I can grab the lexer and parser c files from the 4.10.0-beta1 source release
correct?

[jmckenna@…]

testing on windows...

[jmckenna@…]

testing with 4.10.0-beta2 on Windows I found that INCLUDEs must use a full path,
or this error appears:

  msyylex(): Unable to access file. Error opening included file "parks_include.map".

INCLUDE "E:/ms4w/apps/gmap/htdocs/parks_include.map" --success
INCLUDE "parks_include.map" --fails (both mapfiles are in same dir)

[dmorissette]

Does someone know if includes support relative paths in the Linux version and if
yes what is the path relative to? (I didn't try myself)

Adding Steve to CC. 

[jmckenna@…]

Yes Steve wrote the initial version of the INCLUDE page in the mapfile reference
(http://mapserver.gis.umn.edu/docs/reference/mapfile/Include) and it says "File
location is relative to the location of the mapfile."  Plus all of his examples
in the original bug (bug#279) use relative paths.

[sdlime]

All of Steve's early examples were run using shp2img or a local MapScript script
so this was not seen in testing. Suprised more folks didn't catch in beta,
although nobody does much with the beta's. Anyway, changing the name of this bug
to be more general, changing component and reassigning...

Steve

[sdlime]

Oh, BTW I have updated the documentation to reflect the full path limitation...

Steve

[jmckenna@…]

any plans for this fix on the horizon?

[sdlime]

Yes, I believe I know what to fix (and how) just need to do it. Perhaps this week.

Steve

[sdlime]

Jeff: I have committed a fix to CVS HEAD, can you try on your end and let me
know if it works? I still get a server error if an error condition exists (e.g.
file not found) and will tackle that under this bug too.

Steve

[sdlime]

Fixed error handling so nesting or file-not-found errors are returned to the
various object loading functions in mapfile.c. Right now the error will manifest
itself as a EOF or possibly an identifier error so users will need to look at
the error stack to see what's going on. This can be fixed by returning an error
code specific to INCLUDES and detecting it in every object loader in mapfile.c.

Need confirmation this works before backporting.

Steve

[sdlime]

No feedback so I'll assume all is well. The change has been working fine for me.
I've commited to 4.10 branch. Need to update documentation when 4.10.1 is
release so changing component.

Steve

[jmckenna@…]

sorry for the late response.

I have verified that relative paths now work, with the last nightly build on
Windows.

good work Steve.

[jmckenna@…]

oddly, the relative path problem is back in today's CVS (I just did a CVS build
on windows and can no longer use relative includes).

Is this possible?  Maybe I made a build mistake?

[sdlime]

I just rebuilt completely from CVS and it works fine for me using perl 
MapScript. I checked the source since I was monkeying around in maplexer.l a 
ting bit and the relevant code is still there.

Recall that my monkeying was related to the included files not being closed so 
there is a new fclose on line 491. Could that be causing the problem? Are you 
seeing an error of some kind or ????

Steve

[jmckenna@…]

it must have been a brain fart - whatever errors I was getting are gone.  sorry
for the false alarm.

[jmckenna@…]

updated the include doc:

"File location can be given as a full path to the file, or (in MapServer >=
4.10.1) as a path relative to the mapfile."