pmk-users Mailing List for Pre Make Kit

This snapshot is the last before the 0.10 release of pmk.
It includes the latest changes done on shared libraries support. We are now able to generate a makefile that will build a library following the rules of the used operating system.

A problem is still unresolved on i386 based MacOSX but we are on our way to resolve it for the upcoming 0.10-RC1. It's all about support of assembly files on POSIX systems, if you have any clue on portability of such files you're welcome to contact us.

Feedback is not only welcome but also needed for the project.

Have fun !

As the subject said, the PMK project has migrated from CVS to SubVersion.

The pmk-cvs@ list is now obsolete and pmk-commits@ will replace it as soon as the creation process is done.

Have fun,
Damien

-------- Original Message --------
Subject: [Pmk-devel] vsnprintf implementation
Date: Mon, 18 Jul 2005 21:20:49 +0200
From: Damien Couderc <mip...@us...>
To: pmk...@li...
CC: pmk...@us...

Hi all,
i've done the attached vsnprintf() code for systems that doesn't already
have it. The only missing stuff to be a complete ISO C99 implementation
is the wide char support (AKA %lc and %ls).

It will be included in compat as soon as i'm sure it works fine. This is
why i ask for volunteers to test it and maybe detect things i didn't seen.

You will also found a test.c file that already do some tests.

Thanks for your help,
Damien

Damien Couderc wrote:
> You will find attached to this mail the makefile resulting from the 
> lastest changes to pmkscan i committed few minutes ago.
> 
> This file HAS NOT BEEN EDITED. It has been automatically built by 
> pmkscan after scanning source files of pmk. I'm still working on the 
> object dependency scanning for assembly sources. The C headers with 
> prototypes are not included in the assembly sources so we can't easily 
> found the header by checking the included files. A solution could be to 
> check every headers to find corresponding function names but it costs so 
> much that i prefer trying to find a better way before.
> 
> Of course i'd like to receive feedback about the job actually done. This 
> stuff represent the next 0.10 release of pmk and also adds one more 
> major feature to the project (and also made some feature additions 
> delayed).
> 
> Happy reading,
> Damien

Looks like the attachement disapeared ?!?!

So here it is,
Damien

You will find attached to this mail the makefile resulting from the 
lastest changes to pmkscan i committed few minutes ago.

This file HAS NOT BEEN EDITED. It has been automatically built by 
pmkscan after scanning source files of pmk. I'm still working on the 
object dependency scanning for assembly sources. The C headers with 
prototypes are not included in the assembly sources so we can't easily 
found the header by checking the included files. A solution could be to 
check every headers to find corresponding function names but it costs so 
much that i prefer trying to find a better way before.

Of course i'd like to receive feedback about the job actually done. This 
stuff represent the next 0.10 release of pmk and also adds one more 
major feature to the project (and also made some feature additions delayed).

Happy reading,
Damien

Well i must say that i'm a bit disapointed as i expected at least some
feedback about my previous post. Its more surprising knowing the fact
that some people have already asked for such feature.

Now should i still continue to share my plans for the project or the few
people on those lists aren't so much interested ?
Of course no reply will count as a "no" ...

Damien

PS: BTW i've committed my more recent stuff to the tree and pmkscan now
generate correct object dependencies for each target.

Well i must say that i'm a bit disapointed as i expected at least some 
feedback about my previous post. Its more surprising knowing the fact 
that some people have already asked for such feature.

Now should i still continue to share my plans for the project or the few 
people on those lists aren't so much interested ?
Of course no reply will count as a "no" ...

Damien

PS: BTW i've committed my more recent stuff to the tree and pmkscan now 
generate correct object dependencies for each target.

Hi everybody,
i thought i had to make a little post about recent changes done in the 
current repository.
Those who follow cvs commits could have seen some new stuff imported 
since Easter holidays. This stuff is adding something that has been 
discussed many times about PMK : the pmkscan tool now have both options 
'p' and 'm'. The first being the traditional pmkfile generation from 
sources and the second being the new *makefile* generation option.

YES, you've read about MAKEFILE generation. I still think that makefiles 
have to be polished by hand but it seems that we can help by generating 
templates that will be almost usable without so much further changes.

As an example you could look at the attached example. You will notice 
that the object list are not yet striped. This is a work in progress in 
parallel of the C file parsing engine. I hope to finish it as soon as 
possible. There is also some cosmetics too add like for example some 
formating on the line length. All this should be ok in the next snapshot.

The next step is an idea that comes from Robin Rowe (of cinepaint 
project). The idea is to help simplify the install/deinstall process. 
First we discussed about generating scripts to do such things. But with 
the time i came to another similar concept : pmkinstall will have a 
specific option that will take a file as argument. This file would be in 
the same spirit as the pmkfile but for install purposes. This will allow 
to get rid of shell scripts to a cleaner solution.

In the same time i'm trying to provide more documentation especially for 
developpement of PMK. I'm already looking at doxygen but other 
suggestions are welcome.

I'm also thinking about providing an alternative to the 'make' tool 
always in the same spirit of PMk. But don't enjoy too quickly as it is 
planed after the release of PMK 1.0.

Have fun,
Damien

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...

Hi Quentin,
well the first thing i must do is to warn you about pmk following unix 
standards as a goal. This is not the same playing field than autoconf.

I'm not aware about the gnustep environement so i can't tell you if pmk 
will help. I must admit that i'm a bit afraid when i read that GNUstep 
install don't rely on unix fs layout. Anyway, i think about looking at 
gnustep-make as soon as possible (this means not so soon because i'm 
really busy actually ;).

By the way, are your project's sources publicly available ? This could 
help a bit to see what is done in the source configure stage.

Now speaking about operating systems. I know a few about darwin but 
AFAIK it does not seem to be totally unix compliant so i cannot grant 
that we could resolve all your problem on this platform. I know much 
about OpenBSD which is my default OS.
The main pmk project should never have support windows as it is not a 
unix like system. Maybe one day, there will be a windows port that will 
handle specificities. But it's far from being a promise as i just don't 
care about it (this means i will not do the development).

By the way, reading the last part of your mail i wonder whether your had 
already looked what exactly pmk can do ?
Anyway, getting the environement variables should not be difficult as we 
already got some of them. I just need to think about how it will 
inter-operate with actual gathered data. But i still don't understand 
what is the problem with getting them from make :)

Damien

Le 3 mars 05, =E0 21:15, Damien COUDERC a =E9crit :

> Quentin Math=E9 wrote:
>
>> Hi,
>> I would like to use pmk for a project, but I need to read various =20
>> shell environment variables for library paths, include paths and =20
>> other stuff=85 is this possible with pmk and how to do it ?
>
> Hi Quentin,
> could you be more precise about your needs ?
> Also you could get the env variables directly from the Makefile.

Here is my real reply finally.

Well, it doesn't interest me to check the env variables within Makefile.
Explanations now=85 :-)
My development project is based on GNUstep http://www.gnustep.org then =20=

I'm using gnustep-make (evolved custom Make environment) for my =20
development. When you decide to use GNUstep applications, you need to =20=

run a shell script in order to have a usable environments by setting =20
various env variables (most of the time you can put it in .profile or =20=

similar)

Here are GNUstep specific variables, I need to check some of them in =20
order to verify if the environments is correctly set up for my build =20
process and which flags I need to pass (depending on variables like =20
LIBRARY_COMBO, GNUSTEP_ROOT etc.)

GNUSTEP_LOCAL_ROOT=3D/GNUstep/Local
GNUSTEP_HOST=3Dpowerpc-apple-darwin7.7.0
GNUSTEP_NETWORK_ROOT=3D/GNUstep/Local
GNUSTEP_MAKEFILES=3D/GNUstep/System/Library/Makefiles
GNUSTEP_ROOT=3D/GNUstep
GNUSTEP_FLATTENED=3Dyes
GNUSTEP_HOST_OS=3Ddarwin7
GNUSTEP_HOST_VENDOR=3Dapple
GNUSTEP_HOST_CPU=3Dpowerpc
GNUSTEP_USER_ROOT=3D/Users/qmathe/GNUstep
GNUSTEP_SYSTEM_ROOT=3D/GNUstep/System
GNUSTEP_PATHLIST=3D/Users/qmathe/GNUstep:/GNUstep/Local:/GNUstep/System
CLASSPATH=3D/Users/qmathe/GNUstep/Library/Libraries/Java:/GNUstep/Local/=20=

Library/Libraries/Java:/GNUstep/System/Library/Libraries/Java
LIBRARY_COMBO=3Dgnu-gnu-gnu

Here are extra en variables I can need to check :

LDFLAGS=3D-L/opt/local/lib -L/sw/lib
SHELL=3D/bin/bash
PATH=3D/usr/local/bin:/usr/local/sbin:/gdb/bin:/gcc/bin:/opt/local/bin:/=20=

Users/qmathe/GNUstep/Tools:/GNUstep/Local/Tools:/GNUstep/System/Tools:/=20=

sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
CFLAGS=3D-I/opt/local/include -I/sw/include
CC=3D/gcc/bin/gcc
DYLD_FRAMEWORK_PATH=3D/Users/qmathe/GNUstep/Library/Frameworks:/GNUstep/=20=

Local/Library/Frameworks:/GNUstep/System/Library/Frameworks
DYLD_LIBRARY_PATH=3D/opt/local/lib:/usr/local/lib:/gdb/lib:/gcc/lib:/sw/=20=

lib:/Users/qmathe/GNUstep/Library/Libraries:/GNUstep/Local/Library/=20
Libraries:/GNUstep/System/Library/Libraries

The problem is tricky with Mac OS X because for example by default the =20=

system tries to use Apple GCC libobjc which is not compatible with =20
GNUstep (just relying on a different Objective-C runtime), then I need =20=

to check what is precisely in DYLD_LIBRARY_PATH (when you consider CC =20=

path value especially).

The last two variables which are LD_LIBRARY_PATH equivalent for Darwin =20=

linker are important in my case because I'm doing development most of =20=

the time on top of Mac OS X (aka Darwin with GNUstep running in Apple =20=

X11.

The problem is that I could need to link libraries in /sw (Fink related =20=

packages) or not, this induces possible problems with GCC and linker =20
flags too.

I need to check various stuff like this because the project is rather =20=

complicated and I need to simplify build process as much as I can for =20=

deployment. I encounter similar problems with other OS like =20
DragonFlyBSD or OpenBSD for example because GNUstep install  scheme is =20=

particular (not relying on Unix filesystem layout) moreover theses OS =20=

are using special GCC version, custom filesystem layout etc.

At some point I could need build support on Windows too but not very =20
soon at least :-).

hmm=85
My current workaround would be a wrapper shell script driving pmk =20
process :
- dumping env variables I'm need in a special file
- running pmk which would parse this special file
- returning results
=85 but I would appreciate a better/simpler solution.

Quentin.

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

Le 20 mars 05, =E0 22:01, mips a =E9crit :

> Damien COUDERC wrote:
>
>> Quentin Math=E9 wrote:
>>
>>> Hi,
>>>
>>> I would like to use pmk for a project, but I need to read various=20
>>> shell environment variables for library paths, include paths and=20
>>> other stuff=85 is this possible with pmk and how to do it ?
>>
>> Hi Quentin,
>> could you be more precise about your needs ?
>> Also you could get the env variables directly from the Makefile.
>
> Hi,
> is it me or you didn't replied ? :)

No, it's me :-) Sorry I missed your reply in my inbox =85 I will send a=20=

better reply tomorrow.

Thanks,
Quentin

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

Damien COUDERC wrote:
> Quentin Math=E9 wrote:
>=20
>> Hi,
>>
>> I would like to use pmk for a project, but I need to read various=20
>> shell environment variables for library paths, include paths and other=
=20
>> stuff=85 is this possible with pmk and how to do it ?
>=20
>=20
> Hi Quentin,
> could you be more precise about your needs ?
> Also you could get the env variables directly from the Makefile.

Hi,
is it me or you didn't replied ? :)

Damien

Quentin Math=E9 wrote:
> Hi,
>=20
> I would like to use pmk for a project, but I need to read various shell=
=20
> environment variables for library paths, include paths and other stuff=85=
=20
> is this possible with pmk and how to do it ?

Hi Quentin,
could you be more precise about your needs ?
Also you could get the env variables directly from the Makefile.

Damien

Hi,

I would like to use pmk for a project, but I need to read various shell=20=

environment variables for library paths, include paths and other stuff=85=20=

is this possible with pmk and how to do it ?

Thanks,
Quentin.

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

On Fri, 25 Feb 2005 20:12:29 +0100
mips <mi...@ne...> wrote:

>  > In the general case, a developer finds some bug or feature that can only
>  > be detected at run time and would like to detect the presense/absence
>  > of that feature at configure time.
> 
> Well i disagree with you on that.
> Broken code has nothing to do with dependencies. those bugs have to be 
> fixed upstream. Who would want to run something broken instead of 
> updating to a fixed release ?

Here is a current real world example. The snprintf function is defined
by the ISO C99 standard to have a very specific behaviour with regard to
its return value. However earlier implemtations which are not strictly
compliant still exist. If I have code that expects the C99 behaviour, 
I want to figure out if the C library on the host i am compiling on
is a C99 snprintf or a non-compliant snprintf.

Determining if the snprintf is C99 compliant can only be done with
an AC_TRY_RUN.

> So i expect to stand on my position concerning AC_TRY_RUN until i got a 
> good argument to not do so. 

I suggest that you use the snprintf problem as that argument.

An important feature of the C99 snprintf is (from the man page):

    The  functions  snprintf  and vsnprintf do not write more
    than size bytes (including the trailing '\0').   If  the  output  was
    truncated  due  to  this limit then the return value is the number of
    characters (not including the trailing '\0') which  would  have  been
    written to the final string if enough space had been available. Thus,
    a return value of size or more means that the output  was  truncated.

A common idiom for using snprintf is as follows:

    len = snprintf (NULL, 0, "x = %d, y = %f, z = %s\n", x, y, z) ;
    s = malloc (len + 1) ;
    snprintf (s, len, "x = %d, y = %f, z = %s\n", x, y, z) ;

There are many broken snprintf implementations where snprintf never
returns a value larger than the second parameter passed to it which 
means it cannot be used as in the example.

Yes, I agree that it should be fixed upstream, but upstream has
already fixed the problem; its called the next release of the
operating system. However, I have a client who doesn't want to or
can't do an OS upgrade, but wants to install my code which uses
snprintf in the above manner.

> Concerning the general "issue" you already got my answer 
> above.

Your answer for the general issue doesn't help with snprintf. There
are probably thousands of project whcih currently use autoconf to
detect this exact problem.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  no...@me... (Yes it's valid)
+-----------------------------------------------------------+
Linux: the only OS that makes you feel guilty when you reboot
    -- Kenneth Crudup in comp.os.linux.misc

Damien Couderc wrote:
> Erik de Castro Lopo wrote:
> 
>> On Tue, 01 Feb 2005 17:03:01 +0100
>> Damien Couderc <mip...@us...> wrote:

Wow i just realized that i had been busy so long :)

Damien

Erik de Castro Lopo wrote:
> On Tue, 01 Feb 2005 17:03:01 +0100
> Damien Couderc <mip...@us...> wrote:
>>The
>>solution in my mind was to replace scripts by data files. So the threat
>>is located only in pmk code instead of every configure scripts.
>>
>>Until now we always found an alternative for AC_TRY_RUN and i hope we'll
>>always succeed in that :)
> If you are attempting to replace autoconf, then I think you will fail
> if you cannot provide a facility like AC_TRY_RUN. YOu can replace
> certain specific uses of it, but not the general case.

Hopefully we don't expect to replace autoconf. Our goals are different,
this is why PMK is called an alternative.

> In the general case, a developer finds some bug or feature that can only
> be detected at run time and would like to detect the presense/absence
> of that feature at configure time.

Well i disagree with you on that.
Broken code has nothing to do with dependencies. those bugs have to be
fixed upstream. Who would want to run something broken instead of
updating to a fixed release ?
So i expect to stand on my position concerning AC_TRY_RUN until i got a
good argument to not do so. Anyway if even this happens then PMK has no
future as security is a great part of it's goals.

> The only way to do this in the general case is to provide a feature
> like AC_TRY_RUN, possibly using something like a chroot jail.

Using chroot means the necessity to run pmk as root. I find it a bit
overkill :)

>>I've looked quickly at your m4 macro so i get the main idea of what
>>you're checking. Now i'm wondering if this is a bug or a feature, could
>>you provide me an URL that explain a bit more this phenomenon ?
>
> There is no URL. As far as I am aware, I am the only person who uses
> this "feature".
[detail]
> which I consider the "correct" thing to do. X86 CPUs, only do the
> "correct" thing on negative floats which means I still need an if
> statement to check for positive floats that would overflow.
> Other CPUs? I don't know; so I use AC_TRY_RUN.

Well i'm a bit amazed by this problem. Honestly i don't understand how
you can be the only one to have caught this bug.
I suppose that you must have tested this with many compilers and
operating systems that runs powerpc to be sure it was in the core cpu.
So i wonder whether you tried to contact anybody about that issue ?

> So, I've explained what my M4 macro does, but I urge you not to address
> this specific issue but the general issue that AC_TRY_RUN solves.

Well the way i see that is a check done by pmksetup as it is pure
hardware bug. Concerning the general "issue" you already got my answer
above.

Thanks,
Damien

On Tue, 01 Feb 2005 17:03:01 +0100
Damien Couderc <mip...@us...> wrote:

> Hi Erik,
> i've finaly found some time to check your second problem.
> 
> I knew that one day i'll get this question :)
> One of the reasons that made me starting PMK was the problem that
> occured some time ago with trojans hidden in configure scripts. 

Thats a worthy goal and I applaud you for trying to meet it.

> The
> solution in my mind was to replace scripts by data files. So the threat
> is located only in pmk code instead of every configure scripts.
> 
> Until now we always found an alternative for AC_TRY_RUN and i hope we'll
> always succeed in that :)

If you are attempting to replace autoconf, then I think you will fail
if you cannot provide a facility like AC_TRY_RUN. YOu can replace 
certain specific uses of it, but not the general case.

In the general case, a developer finds some bug or feature that can only
be detected at run time and would like to detect the presense/absence
of that feature at configure time.

The only way to do this in the general case is to provide a feature
like AC_TRY_RUN, possibly using something like a chroot jail.

> I've looked quickly at your m4 macro so i get the main idea of what
> you're checking. Now i'm wondering if this is a bug or a feature, could
> you provide me an URL that explain a bit more this phenomenon ?

There is no URL. As far as I am aware, I am the only person who uses
this "feature".

Both of my libraries contain code for doing conversions of floats/doubles
in the range [-1.0, 1.0] to shorts and ints. On top of that, if the source
float/double would overflow the destination short/int, them the float/
double should be clipped to the maximum allowable value of the destination
format before the conversion. The naive implementation of a float to
short conversion with clipping is :

     inline short f2s (float src)
     {    src *= 32767.0 ;
          if (src > 32767.0)
             return 32767 ;
          if (src < -32768.0)
             return -32768 ;
          return (short) src ;
     }
 
When doing this on large arrays of numbers, the two if statements slow
down execution significantly. However on PowerPC, I know that I can 
replace the above code with:

     inline short f2s (float src)
     {    int dest = (int) (src * MAX_INT) ;
          return (src >> 16) ;
     }

By removing the two if statements, the above code runs significantly
faster and produces the same result. The "trick" is that when a 
float is converted to an int on PowerPC, the CPU automatically, in
silicon, does this :

     if (src > MAX_INT)
         dest = MAX_INT ;
     else if (src < MIN_INT)
         dest = MIN_INT ;
     else
         (int) src ;

which I consider the "correct" thing to do. X86 CPUs, only do the 
"correct" thing on negative floats which means I still need an if
statement to check for positive floats that would overflow.
Other CPUs? I don't know; so I use AC_TRY_RUN.

So, I've explained what my M4 macro does, but I urge you not to address
this specific issue but the general issue that AC_TRY_RUN solves.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  no...@me... (Yes it's valid)
+-----------------------------------------------------------+
"Always code as if the person who ends up maintaining your
code will be a violent psychopath who knows where you live."
-- Martin Golding

Erik de Castro Lopo wrote:
> Hi all,
> 
> I'm the main author of libsndfile and libsamplerate and I'm
> investigating alternatives to automake/autoconf/libtool.
> 
> Currently I have a number of custom M4 macros that use AC_TRY_RUN
> to detect specific features of the host CPU (with defaults for
> cross compiling). An example would be:
> 
>     http://www.mega-nerd.com/tmp/clip_mode.m4
> 
> So, if I wanted to do a test like that, would that test have to 
> be built into the pmk binary/data files or does pmk have some
> other way of doing it?

Hi Erik,
i've finaly found some time to check your second problem.

I knew that one day i'll get this question :)
One of the reasons that made me starting PMK was the problem that
occured some time ago with trojans hidden in configure scripts. The
solution in my mind was to replace scripts by data files. So the threat
is located only in pmk code instead of every configure scripts.

Until now we always found an alternative for AC_TRY_RUN and i hope we'll
always succeed in that :)
I've looked quickly at your m4 macro so i get the main idea of what
you're checking. Now i'm wondering if this is a bug or a feature, could
you provide me an URL that explain a bit more this phenomenon ?

Damien

The bugfix release 0.9.2 has been released.

Damien

Hi all !

Due to lack of testers the 0.9.1 release has been provided with two 
bugs. The first is that using pmksetup with -v argument is flushing the 
configuration file content. The second is leaving the temporary file of 
pmksetup if ran without correct privileges.

The attached diff is splitting the arguments parsing in two parts : the 
first part is now in main() and process -v and -V flags that are safe 
while in privileged mode. The other allowed arguments are parsed in the 
child (non privileged) part to reduce risks.

The result is that -v is exiting really early now. The renaming/saving
part of the configuration file is now done only if child status is okay.

Another change is that the temporary file is also written in the same 
directory than the configuration file. This directory is also checked 
and created earlier than before to avoid running tests if the results 
cannot be written.

If you have some time to review and test this diff i'd be happy to get 
some feedback to quickly release a bugfix release.

Cheers,
Damien

This release include privilege separation for pmksetup when used with 
root privileges. Cpu detection support for ia64 and alpha processors has 
also been added. The decision to keep the original path separator (aka 
':') has been taken to keep compatibility and to avoid too much useless 
processing of the data. This change means that you absolutely need to 
update your pmk.conf before using pmk. See the changelog for more details.

Have fun,
Damien

Erik de Castro Lopo wrote:
> I think you missed the point. The above is a valid test for endian ness,
> but I'm more interested in knowing how the detected endinaness is
> represented in the resulting config.h file.
> 
> If it is represented as the presense or absense of a #define then it is
> wrong.
> 
> It must represented like this for big endian:
> 
>     #define    WORDS_BIGENDIAN     1
>     #define    WORDS_LITTLEENDIAN  0
> 
> and this for little endian:
> 
>     #define    WORDS_BIGENDIAN     0
>     #define    WORDS_LITTLEENDIAN  1

The result is that the HW_BYTEORDER tag is set to one of the three 
following values:
LITTLE_ENDIAN
BIG_ENDIAN
UNKNOWN_ENDIAN

Then everybody is able to transform this information in respect to their 
need.

Damien

On Tue, 25 Jan 2005 18:00:00 +0100
mips <mi...@ne...> wrote:

> Hi Erik,
> well the tutorial is still a work in progress and its content is not 
> reflecting all the capabilities of pmk.
> The pmksetup tool is using the following code since some time now:
> 
> 	if (((((char *)&num)[0]) == 0x41) && ((((char *)&num)[1]) == 0x42) &&
> 	    ((((char *)&num)[2]) == 0x43) && ((((char *)&num)[3]) == 0x44)) {
> 		strlcpy(bo_type, HW_ENDIAN_BIG,
> 				sizeof(bo_type)); /* should not fail */
> 	} else {
> 		if (((((char *)&num)[3]) == 0x41) &&
> 				((((char *)&num)[2]) == 0x42) &&
> 				((((char *)&num)[1]) == 0x43) &&
> 				((((char *)&num)[0]) == 0x44)) {
> 			strlcpy(bo_type, HW_ENDIAN_LITTLE,
> 					sizeof(bo_type)); /* should not fail */
> 		} else {
> 			strlcpy(bo_type, HW_ENDIAN_UNKNOWN,
> 					sizeof(bo_type)); /* should not fail */
> 		}
> 	}
> 
> 
> I suppose this is exactly what you're looking for, isn't it ?

I think you missed the point. The above is a valid test for endian ness,
but I'm more interested in knowing how the detected endinaness is
represented in the resulting config.h file.

If it is represented as the presense or absense of a #define then it is
wrong.


It must represented like this for big endian:

    #define    WORDS_BIGENDIAN     1
    #define    WORDS_LITTLEENDIAN  0

and this for little endian:

    #define    WORDS_BIGENDIAN     0
    #define    WORDS_LITTLEENDIAN  1

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  no...@me... (Yes it's valid)
+-----------------------------------------------------------+
"I believe C++ instills fear in programmers, fear that the interaction
of some details causes unpredictable results. Its unmanageable complexity
has spawned more fear-preventing tools than any other language, but the
solution _should_ have been to create and use a language that does not
overload the whole goddamn human brain with irrelevant details."
-- Erik Naggum