Set Include Path Per script?

[SpinningCone]

OK so long story short about a year ago I upgraded auto it and have pretty much had problems since.  Mostly stemming from the fact that my scripts were old enough to be using different library file versions. 

Since a bunch of my stuff does production level work I can't afford to have it break on every update so what I want to do is isolate all the include files per script. ie each new script would get it's own folder for the au3 and a complete copy of the libraries at the time it was written. Thus all it's dependencies   would be self contained and each script could be upgraded individually.

Now I know I can explicitly put a path for my includes. for example if i had array.au3 i could copy that library to the project then explicitly point to the copy . however array.au3 has it's own includes which will point back to the install root, and those includes could have includes etc etc. hand editing each library isn't practical.

Is there a way to indicate at the top of a script where the include folder is (without doing a registry hack each script) ?

 

[AdamUL]

You can run different versions of AutoIt while you are upgrading your scripts.  Extract the zip files for the older AutoIt3 versions with their older libraries and use them.  Use the following to set the AutoIt3Wrapper directive to set AutoIt Directory.  

#AutoIt3Wrapper_Autoit3Dir=C:\Program Files\AutoIt3\3.3.8.1  ;Optionally override the AutoIt3 install directory to use.

 

Adam

[JohnOne]

Or compile older scripts.

[SpinningCone]

Hmm that might work, though it'd be nice not to have to copy a full auto-it install for each, I might give that a try.

 

Compiling isn't a solution (most of these run compiled anyway) , if i need to fix a bug or add a feature or make any change I need the  original script working.

[JohnOne]

Do you have any ideas on another possible direction which could be taken?

Perhaps it could spark a further idea.

[SpinningCone]

Ive considered writing (in autoit ironically) a dependency manager that would open a script parse all the includes, make sure they were copied to the include folder in a project  then recursively find all the includes of the includes etc etc and then re-write each library include to point to the local directory.

 

   It would be relatively portable as I could zip the project folder and take the whole file structure with me. an advantage here is that it would only need copies of the actual dependencies not the whole include directory. a disadvantage is that there might still be incompatibilities especially if later i add a library that had the same base dependency (like a GUI or Array library) and now there's two different versions. that contingency could be handled but it could get messy fast.  another disadvantage is needing to take the time to write such a utility. 


Overall i was hoping for a line similar to the wrapper line that AdamUL mentioned except rather than point to an install directory where it expects a full autoit install just point to the include directory.  While I could still get incompatibility with later versions of autoit generally the newer version of autoit itself handle s the older libraries just fine and it would be a big step up.


Overall I'm not sure what the "ideal" dependency management would be , maybe if all core libraries had versions and a version history were maintained. ie under include was "old versions" and the #include <> statement could take a version as a parameter, if that version wasn't found it would look in the old versions folder and try to find the old version.

might looks something like :

+include
     Date.au3
     +old versions
             Date-1.0.au3
             Date-1.1.au3
             Date-2.2.au3
              .
              .

Then old version dependencies could be installed independently as they would only be used in scripts that provided a version parameter.

[JohnOne]

Problem with that, is if the native functionality has changed.

I thought you were looking for a stop gap while you updated your scripts.

How old is the version you are using, it would probably be simpler just to update your scripts against the script breaking changes in the history log.

You could also run obfuscator on them with certain switches and the script will be self contained without being compiled.

I think the SO switch is the one to use, creates one au3 file containing all the includes.

[SpinningCone]

Different scripts are different age and respond differently , now that I think about it I do have one that works but can no longer compile (there's a parsing error in one of the libraries, but it runs from the editor, i think it's an AU check compatibility issue but haven't spent much time investigating)  another I had issues with file.au3 where in the new version _FileWriteToLine() decided that it should delete the last CRLF of a file when called. this caused parsing problems with a flat file I had when it would later add content to said file (or parse it expecting a final EOL). 

some scripts go a long time without needing anything then might need an update (years), others get more frequent updates (months).  I hope to try to get everything on the same page and all working again with the latest versions but moving forward I need to mitigate the issues

Though it's more stuff it's probably the best will be to just use the wrapper and maintain a full version of autoit for each project.  It creates a ton of bloat but in the end it should allow me to have a known good working library/autoit pair preserved for making updates.  I might still develop a little dependency manager utility to help with upgrading and then write a bunch of documentation for handling the project files.

 

[BrewManNH]

In the future, you can use Au3Stripper with the /so parameter and that would create a script with all of the used includes in it and then you'd have a fully functioning script that won't need any includes.

[SpinningCone]

23 minutes ago, BrewManNH said:

In the future, you can use Au3Stripper with the /so parameter and that would create a script with all of the used includes in it and then you'd have a fully functioning script that won't need any includes.

Hmm, might work, though I'm not sure if it will make maintenance harder or easier. I've not used that before so i'll ahve to look at the output and really see the results and how it works with project maintenance.