NO

Author Topic: POLINK: environment variable LIB  (Read 5798 times)

mtx500

  • Guest
POLINK: environment variable LIB
« on: May 09, 2005, 03:41:04 PM »
The environment variable LIB is documented for POLINK, but does not seem to work ?! Pelle, would you please have a look into it? Thanks!

I have to use option /LIBPATH:<directory> instead. This is unconvenient, as it can only add one directory at a time so I have to specifiy all directories in my makefile separately instead of saying /LIBPATH:$(LIB). This forces me to use absolute path names in my makefile, which I'm trying to avoid for portability reasons.

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2266
    • http://www.smorgasbordet.com
Re: POLINK: environment variable LIB
« Reply #1 on: May 09, 2005, 04:48:08 PM »
Hm. It's working here - on Windows XP (from the command line).

If you use /LIBPATH, those directories will be searched before the environment var LIB. Are you sure the environment var is OK? Maybe using the linker option /verbose will help?

Pelle
/Pelle

mtx500

  • Guest
POLINK is ok, but ...
« Reply #2 on: May 10, 2005, 11:08:34 AM »
After further investigation, I found out the real cause:

Environment variable LIB is working as expected with polink, but the behaviour of pomake regarding environment variables is not as I expected.

In the makefile, I am using macros for the executables, i.e. $(CC) for pocc.exe and - you guessed it by now - $(LIB) for polib.exe.

Now I knew that environment variables are imported as predefined macros when the make utility starts. But what pomake is obviously doing and which I wasn't aware of, is that it exports all its macros as environment variables to all the programs it starts. I was expecting that the programs get the same environment variables that the make utility had when it was starting, and that macros only have a meaning inside the makefile.

I'm checking what other make utilities do with macros/environment variables and will report soon here.

mtx500

  • Guest
POLINK: environment variable LIB
« Reply #3 on: May 10, 2005, 01:16:40 PM »
Here are the results of my short survey.

The following make utilities put all make macros into the environment of the called programs:

Pelles pomake, GNU make, Microsoft nmake, and OpenWatcom nmake clone

The following do not:

Borland make, Digital Mars make, OpenWatcom wmake

So there doesn't seem to be a consensus here. As I worked heavily with Borland's make, it is clear where I got my expectation from :-)

Sorry to bother you, I now withdraw this bug report.

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2266
    • http://www.smorgasbordet.com
POLINK: environment variable LIB
« Reply #4 on: May 10, 2005, 04:31:31 PM »
No problem! Thanks for the info. Maybe the POMAKE option /E can be used?

Pelle
/Pelle

mtx500

  • Guest
POLINK: environment variable LIB
« Reply #5 on: May 13, 2005, 12:44:48 PM »
No, /E does not work in this case :cry:
I get
Quote

POMAKE: fatal error: The filename, directory name, or volume label syntax is inorrect.


That's because with /E pomake always uses the contents of the LIB environment variable and ignores my setting of LIB to polib.exe in the makefile. It thus tries to call the library path instead of polib.exe, which of course does not work.

Is this what the /E switch is supposed to do? Reading the help file, I would have thought it only changes the environment of the called commands, but not the handling of macros inside the makefile.

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2266
    • http://www.smorgasbordet.com
POLINK: environment variable LIB
« Reply #6 on: May 14, 2005, 12:47:59 AM »
Quote from: "mtx500"
Is this what the /E switch is supposed to do? Reading the help file, I would have thought it only changes the environment of the called commands, but not the handling of macros inside the makefile.

What it does at the moment is preventing environment variables from being updated (you can read their values, but nover change them). This is what the help file tries to say, but it can be clearer...

Sorry if I mislead you here. I will see if I can find a better way of handling this in the future.  

Pelle
/Pelle