Re: [Pmk-users] Environment variables with pmk

[<gnu...@cl...>]

Le 23 mars 05, =E0 21:12, Damien Couderc a =E9crit :

> Hi Quentin,
> well the first thing i must do is to warn you about pmk following unix=20=

> standards as a goal. This is not the same playing field than autoconf.

ok.

> I'm not aware about the gnustep environement so i can't tell you if=20
> pmk will help. I must admit that i'm a bit afraid when i read that=20
> GNUstep install don't rely on unix fs layout.

hehe. It uses (on top of Unix file system layout) a layout similar to=20
Mac OS X

	Mac OS X					GNUstep variant

/Applications			GNUSTEP_ROOT/Local/Applications

/Network				GNUSTEP_ROOT/Network/
=09
/System 				GNUSTEP_ROOT/System

/System/Library		GNUSTEP_ROOT/System/Library

/Library				GNUSTEP_ROOT/Local/Library

~/Library				GNUSTEP_USER_ROOT/Library

~/Applications			GNUSTEP_USER_ROOT/Applications

This list isn't truly complete, it is just to give you an idea.

> Anyway, i think about looking at gnustep-make as soon as possible=20
> (this means not so soon because i'm really busy actually ;).

Thanks :)

> By the way, are your project's sources publicly available ? This could=20=

> help a bit to see what is done in the source configure stage.

The source are available on GNA.org :=20
http://cvs.gna.org/viewcvs/etoile/Etoile/
however the project is going to move soon because we are merging with=20
another similar project.

> Now speaking about operating systems. I know a few about darwin but=20
> AFAIK it does not seem to be totally unix compliant so i cannot grant=20=

> that we could resolve all your problem on this platform.

Well most of current Unixes like Linux, some BSD too iirc are not fully=20=

Unix compliant anyway.
Darwin is derived from FreeBSD then I don't think it should be a=20
problem.

> The main pmk project should never have support windows as it is not a=20=

> unix like system. Maybe one day, there will be a windows port that=20
> will handle specificities. But it's far from being a promise as i just=20=

> don't care about it (this means i will not do the development).

Even with MinGW or Cygwin ?
GNUstep uses them for compatibility with its Unix history.

> By the way, reading the last part of your mail i wonder whether your=20=

> had already looked what exactly pmk can do ?

Yes, I have even played with it. And in the project CVS there is a=20
pmkfile to prove it ;-)=85 but well it's not working currently.

> Anyway, getting the environement variables should not be difficult as=20=

> we already got some of them.

Good to hear.

> I just need to think about how it will inter-operate with actual=20
> gathered data. But i still don't understand what is the problem with=20=

> getting them from make :)

For example, depending on LIBRARY_COMBO values, the project may only be=20=

partially compiled and we need to tell the user about such incomplete=20
build in order to be sure he doesn't really want a complete build. I=20
could check that with makefile but it would be less clean in my=20
opinion.
I can do an identical thing with libobjc (Apple vs FSF version) by=20
checking DYLD_LIBRARY_PATH value in makefile, but it would be less=20
clean probably too because it is more related to configuration part=20
than compilation part.
We use configuration tools when we want to tweak build/install process=20=

in a precise way, and to avoid checking stuff which rarely changes when=20=

we recompile regularly. May be I'm missing particular points in my=20
comparison between configure step and build step ?

Anyway currently I could put theses specific checks in makefile and=20
wait for a next pmk version to read env vars directly in pmkfile.

Thanks,
Quentin.

--
Quentin Math=E9
qm...@cl...