Jump to content


[AHK_L] #include <lib> breaks the #include directive


  • Please log in to reply
9 replies to this topic

#1 Guests

  • Guests

Posted 20 June 2012 - 12:02 PM

When the #include <lib> directive is used, any following use of a normal #include file.ahk fail because the include directory is modified by #include <lib>.

Refer to this topic <!-- l --><a class="postlink-local" href="http://www.autohotkey.com/community/viewtopic.php?f=3&t=87776">viewtopic.php?f=3&t=87776</a><!-- l --> for the possible consequences of this behabior.

#2 HotKeyIt

HotKeyIt
  • Fellows
  • 6134 posts

Posted 21 June 2012 - 06:43 PM

It looks like this has been already fixed in AHKv2 :)

#3 Lexikos

Lexikos
  • Administrators
  • 8856 posts

Posted 25 June 2012 - 04:40 AM

This will be fixed in the next v1.1 release.

HotKeyIt, it was fixed unintentionally in v2 when the behaviour was changed:

#Include is now relative to the directory containing the current file, by default.



#4 Guests

  • Guests

Posted 26 June 2012 - 10:19 PM

#Include is now relative to the directory containing the current file, by default.

Could we have this new behavior in v1.1 please?

I can't tell you how annoying is when you include libraries of functions which in turn include other ahk files and so on :cry:

If this might potentially break existing code, could we at least have an alternative way of selecting this new behavior in v1.1?
May be a new #IncludeRelative directive, or an optional second parameter in #include. Something like #include ..\functionLib.ahk, true

Pleaseeeee.... :(

#5 fragman

fragman
  • Members
  • 1591 posts

Posted 26 June 2012 - 10:50 PM

I think that #include .\functionLib.ahk would suffice because .\ is not supported right now AFAIK.

#6 Guests

  • Guests

Posted 27 June 2012 - 12:48 AM

I think that #include .\functionLib.ahk would suffice because .\ is not supported right now AFAIK.

That's not it.

Let's suppose we have the following files:

[*:2zaxqxq0]C: \ functionLib.ahk
[*:2zaxqxq0]C: \ moreFunctions.ahk
[*:2zaxqxq0]C: \ myScripts \ script1.ahk
script1.ahk:
include ..\functionLib.ahk
...
functionLib.ahk:
#include moreFunctions.ahk
...
File ..\functionLib.ahk is included correctly, but moreFunctions.ahk is not even though moreFunctions.ahk and functionLib.ahk are in the same directory.
This problem was fixed in v2, but in v1.1 we still have it. And I guess changing it could possibly break existing code. That's why I ask for an alternative fix in v1.1. For example, an optional second parameter to distinguish between the old (bad) behavior and the new (good) behavior.

#7 Lexikos

Lexikos
  • Administrators
  • 8856 posts

Posted 27 June 2012 - 02:48 AM

... because .\ is not supported right now AFAIK.

Yes it is. I suppose that any path syntax supported by Windows should work. .\file is equivalent to file. It is relative to the current #include working directory, which by default depends on what launched the script, except in library files (auto-includes and #include <lib>).

I agree that the current behaviour is far from ideal, but I am loath to introduce any new syntax exclusive to v1.x, or to introduce more inconsistencies between v1.0 and _L.

I tend to use code similar to this:

script1.ahk:
#include ..
#include functionLib.ahk
...
functionLib.ahk:
#include moreFunctions.ahk
...
It can be difficult if script1.ahk includes more files which aren't in "..", or if script1.ahk is itself an include.

#8 fragman

fragman
  • Members
  • 1591 posts

Posted 27 June 2012 - 08:06 AM

... because .\ is not supported right now AFAIK.

Yes it is. I suppose that any path syntax supported by Windows should work. .\file is equivalent to file. It is relative to the current #include working directory, which by default depends on what launched the script, except in library files (auto-includes and #include <lib>).

Good to know, didn't see it in the docs so I assumed it wasn't supported and could be used as syntax to access the current directory.

#9 Lexikos

Lexikos
  • Administrators
  • 8856 posts

Posted 27 June 2012 - 09:08 AM

. = current directory = working directory (only set by #include dir at the early stage where #include is processed)

Maybe by "current directory" you mean the one the file currently being processed is in, but that directory isn't really current since it isn't used for anything.

#10 fragman

fragman
  • Members
  • 1591 posts

Posted 27 June 2012 - 01:42 PM

My post was somewhat imprecise, sorry for that. You interpreted it correctly though, I meant the directory of the script that is currently being processed, not the working directory.