Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

EnvVars Plugin and PATH

<< < (4/9) > >>

pkrcel:
The project is already minimalistic, is a VERY simple allegro tutorial :)

Attached is the project zip file, I haven't stripped any info (except objs and exes!), and there is also the default.conf file.

The problem of course occurs only wih the dyanmically linked exes (targets Release_dyn and Debug_dyn).

To achieve this "error":

 - select a Dyn target (either one), and press "run"....usually the first time all goes fine and you shoul receive a "it's all good" messagebox
 - press "build", you should get a "target up to date" message in the build log window.
 - press "run" again, now you should get the "cannot find allegro monolith dll" error message.

Obviously enuff, the allegro monolith dll should not reside in your PATH or along the Dyn exes..this iis what I am using the envVars plugin for

I am running Win7 and nothing chanfges if I run C::B in admininstrator mode....

MortenMacFly:

--- Quote from: pkrcel on February 11, 2012, 10:54:15 am ---Attached is the project zip file, I haven't stripped any info (except objs and exes!), and there is also the default.conf file.

--- End quote ---
You do have one, trust me, you find it either under ~/.codeblocks (Linux) or in %APPDATA%\codeblocks on Windows. Notice that you don't need to provide the whole file, just the envvars section (you can open it with a XML capable editor like Code::Blocks). But remember DO NOT MODIFY THIS FILE!!! Just extract the content requested to a new file.

pkrcel:
Of course I have that file, I thought I have included it into the previous ZIP.

Here is the ennvars section anyway:


--- Quote ---   <envvars>
      <sets>
         <default />
         <liballeg>
            <ENVVAR0>
               <str>
                  <![CDATA[1|PATH|%PATH%;C:\Users\Provasi\_user\Coding\Libraries\allegro-5.0.5-mingw-4.5.2\bin;C:\MingW\bin]]>
               </str>
            </ENVVAR0>
         </liballeg>
      </sets>
      <ACTIVE_SET>
         <str>
            <![CDATA[liballeg]]>
         </str>
      </ACTIVE_SET>
      <DEBUG_LOG bool="1" />
   </envvars>

--- End quote ---

MortenMacFly:

--- Quote from: pkrcel on February 11, 2012, 10:54:15 am --- - select a Dyn target (either one), and press "run"....usually the first time all goes fine and you shoul receive a "it's all good" messagebox
 - press "build", you should get a "target up to date" message in the build log window.
 - press "run" again, now you should get the "cannot find allegro monolith dll" error message.

--- End quote ---
Works fine here. However, your project settings are really screwed. you hard-code path, path's to libs and use full path's for the names of the libs. So I had to completely modify what you did to use relative path's and (compiler / linker) include path's.

Maybe that's the reason it works for me, but I hit compile/run several times, it always worked. I even switched targets in between - worked, too. (Win7, non-admin).

Maybe you should try to setup your project in a better way: Never use path's for libs to link against: Only use lib names and let the linker know where to search for the libs by providing the linker include path's accordingly. The same applies to the compiler.

Also, I saw you link against DLL's. While this might be correct and work, on MinGW you usually line against an import library for DLL's. So, just "try again" please... ;-)

And btw: You should never need to run C::B as an admin. If you do, something is wrong on your side. C::B does not require admin rights. It would be really bad if it would.

pkrcel:
Okay Morten, I am following your instructions...but I am unable to make it work, I always experience the same problem. :(

- I cleaned up the search paths for linker and compilier defining a global compiler/linker varible "liballeg" that points to the location in which lib allegro is installed and use variable expansion such as $(#liballeg.include) and $(#liballeg.lib)

I've put the library names in linker settings as libgdiplus, trimming out the leading path (man, that was UGLY! this happen when you follow certain instructions without using your brain  :-X, I'm truly ashamed)

I now link against the library "liballegro-5.0.5-monolith-md" instead of the DLL itself (even thou the dll is compiled with MingW...that's why it worked before I guess: ref).

Compiling and linking works fine (no, it works BETTER ;D) as before...but I run into the same problem with PATH, I relativized it to $(#liballeg.obj) having defined obj ans the \bin subfolder but behavior is exactly the same as before.

I also deleted the "liballeg" set of variables and defined PATH in the "default" set but again the behavior is the same.

Question: is there a way to see the value of PATH at any time inside C::B focus?

Navigation

[0] Message Index

[#] Next page

[*] Previous page