[Tips] Reusable Library Directories
July 4, 2017 at 9:11 pm #9132
If you want to avoid duplicating your libraries over and over again across various projects you can follow this approach.
Making directory links in Linux should be like this:1ln -s /.../Monkey2Libraries ./libraryJuly 5, 2017 at 5:05 am #9135
why not just use something like:1#import "../opengl/rameses3d"
where ../ goes to the folder above the current folder?July 6, 2017 at 1:25 am #9143
Yeah this is another good approach, I have seen that various open source projects are based on this approach, such as Blender. I would choose this one if the project was very streamlined and active, it would worth an appropriate file system setup.1234567891011+MonkeyLibraries|+---+Rameses3D+MonkeyProjects|+---+Project1|+---+Project2|+---+Project3
In my hard disk, everything is very unorganized – among various drives and cloud data. Also since I started organizing the projects based on date the file system relations become even more distributed.
I would hope that Monkey2 perhaps in the future might support include and lib parameters, so things become a little flexible there.July 6, 2017 at 5:46 am #9148
then it would be something like this:
<span class=”crayon-o”>#</span><span class=”crayon-r”>import</span> <span class=”crayon-s”>”../../MonkeyLibraries/rameses3d/rameses3d”</span>
lets say you are in project2
../ takes you to MonkeyProjects
../../ takes you to the core folder (lets say monkey2)
../../MonkeyLibraries takes you to the monkey libraries
from there you can go to your libraries projectJuly 7, 2017 at 2:00 am #9159
In this example the libraries and projects are placed in the same directory. But in a real case of where this approach would be useful is this. 🙂1234567891011121314+ D:\Programming\MonkeyLibraries|+---+ GameEngine|+---+ Rameses3D|+---+ Collision|+---+ InputC:\Tests\Project1D:\MonkeyProjects\Project2E:\USBStorage\Project3P:\Programming\Project4July 26, 2017 at 10:45 pm #9527
You could use environment variables too, couldn’t you?July 28, 2017 at 5:45 am #9570
Where?August 6, 2017 at 11:01 pm #9752
Sorry for the late reply.
In Windows (Not sure about other OS’s ATM) you can add an “Environment Variable.”
Essentially they’re “Global” variables used when executing commands via “system(‘echo %PATH%’);” in the standard sense.
So in a sense, you could add a directory path to your %PATH% system variable containing your modules, and if it’s implemented in MX2CC it should compile just fine. This is how your system knows where DLL’s/Modules are installed or for any required purpose.
I haven’t tested if this works yet or not, but it should to keep source management a bit less “copy & pasty”
and it’s only a few clicks in the Control Panel. So you don’t have to dig too deep and possibly mess something up.
However, good job one finding another way with added benefits! I honestly didn’t know you could achieve this like you did. 5/5August 7, 2017 at 11:39 pm #9764
From what I see, I can open a file from command prompt nicely, but the monkey2 compiler can’t figure out the location of the file. I wonder if it’s related to the reason that monkey can’t load full-paths as well. 🙂
You must be logged in to reply to this topic.