Hello
unifdef is not only very old and unmaintained, the binary does not work
and the source does not compile on a pure x86_64 system. There is
another tool that worked for me--though it 'closed with remarks'--and
that was updated recently (several times this year). It is called
sunifdef, is under an equal (new) BSD license, and is proposed to be
the successor of unifdef. See the project page:
http://www.sunifdef.strudl.org/
Regards,
Dennis
On Thu, Oct 05, 2006 at 03:08:16PM +0200, Dennis Heuer wrote:
> unifdef is not only very old and unmaintained, the binary does not work
> and the source does not compile on a pure x86_64 system. There is
> another tool that worked for me--though it 'closed with remarks'--and
> that was updated recently (several times this year). It is called
> sunifdef, is under an equal (new) BSD license, and is proposed to be
> the successor of unifdef. See the project page:
>
> http://www.sunifdef.strudl.org/
What about posting compiler errors instead of suggesting something that
is 10 times bigger?
On Thu, 2006-10-05 at 15:08 +0200, Dennis Heuer wrote:
> unifdef is not only very old and unmaintained, the binary does not work
> and the source does not compile on a pure x86_64 system.
It works for me. Describe your problem more coherently.
I wouldn't describe it as 'very old' -- the last commit seems to have
been last March, which isn't _so_ recent but perhaps it just hasn't
_needed_ an update?
Neither would I describe it as unmaintained. Tony was quite quickly
responsive when I asked him if it would be OK to include unifdef in the
kernel source tree.
> There is another tool that worked for me--though it 'closed with
> remarks'--and that was updated recently (several times this year). It
> is called sunifdef, is under an equal (new) BSD license, and is
> proposed to be the successor of unifdef. See the project page:
>
> http://www.sunifdef.strudl.org/
I don't see a huge point in changing, unless it lets us get rid of stuff
like
#if defined(__KERNEL__ && ....
when used with -U__KERNEL__.
--
dwmw2
On Thu, 5 Oct 2006, David Woodhouse wrote:
>
> I wouldn't describe it as 'very old' -- the last commit seems to have
> been last March, which isn't _so_ recent but perhaps it just hasn't
> _needed_ an update?
>
> Neither would I describe it as unmaintained. Tony was quite quickly
> responsive when I asked him if it would be OK to include unifdef in the
> kernel source tree.
I haven't received any contributions to unifdef in the last 18 months
which is why it hasn't changed. Yes, it has some significant gaps in its
functionality, but it's reasonably correct within its current scope. (I
tend to think that if you need more advanced functionality then you are
already in serious trouble: for example, my unifdef was written so that I
could understand xterm's frightening pty handling....) I don't have a lot
of time to make extensive changes to unifdef, and given that sunifdef
exists there is not much point. Thanks for telling me about it: I didn't
know it existed, and it's nice to see other people basing such great stuff
on my work.
> I don't see a huge point in changing, unless it lets us get rid of stuff
> like
> #if defined(__KERNEL__ && ....
I don't think your syntax errors are my problem :-)
Tony.
--
f.a.n.finch <[email protected]> http://dotat.at/
FORTIES CROMARTY FORTH: SOUTHERLY 6 TO GALE 8, DECREASING 5 OR 6 LATER. RAIN
OR SHOWERS. MODERATE OR GOOD.
On Thu, 2006-10-05 at 17:05 +0100, Tony Finch wrote:
> > #if defined(__KERNEL__ && ....
>
> I don't think your syntax errors are my problem :-)
Heh, good point :)
--
dwmw2
> I haven't received any contributions to unifdef in the last 18 months
> which is why it hasn't changed.
Reminds me - I did a small change to avoid dependency on strlcpy.
You can see it here:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14a036d2dc304797f3624c06bd6d2a1e9b59e45a
I strongly preferred 8 simple codelines as replacement for carrying
strlcpy in a seperate file. Feel free to include this in your unifdef
as you whish.
Sam
Ok, I may have been too hasty in calling it dead. However, I don't know
where you got it from but I just did a google and found nothing
original. Only deps, rpms, and so forth. I started a search at
Freshmeats and found it besides sunifdef. The freshmeat entry was from
2000 and the last noted update was from 2001. There was no link to a
homepage but just a link to one specific release (Possibly there are
newer ones already.)
And, 10 times bigger is not an argument neither for nor against a
tool. I'd rather like to see unifdef slip from my harddisk in full. Now,
you decided to use this tool. Ok! So what about some more global
perspective. Shouldn't it be useful for others too, then (So that it's
not only on disk for your project.) I at least pledge for sunifdef
compatibility, which should be possible because I already installed the
headers with it (though it produced some 'remarks', there doesn't seem
to be a difference between this installation and a previous one on my
old system--except that in the latter case I lost all other files
in /usr/include because there was no hint blinking anywhere that 'make
headers_install' would not just copy to but overwrite the include
directory. Playing with INSTALL_HDR_PATH, thus, is quite dangerous!)
However, there are three main reasons why I pledge for sunifdef
compatibility:
1. There is a project page and an inviting community
2. There is HTML documentation
3. They use autotools, which is distributor and administrator-friendly
(just works like the rest, and installation can be automated together
with other packages in one rush and with one simple script that uses
one strategy--very nice that is!)
Now to unifdef. Got it working. An old .o file caused the problem.
Still there is an error output:
gcc -O2 -m64 -c -o unifdef.o unifdef.c
unifdef.c: In function 'main':
unifdef.c:129: warning: incompatible implicit declaration of built-in
function 'exit'
unifdef.c:157: warning: incompatible implicit declaration of built-in
function 'exit'
unifdef.c:180: warning: incompatible implicit declaration of built-in
function 'exit'
gcc unifdef.o -o unifdef
Regards,
Dennis
Ps: am off the list now.
> However, there are three main reasons why I pledge for sunifdef
> compatibility:
>
> 1. There is a project page and an inviting community
> 2. There is HTML documentation
> 3. They use autotools, which is distributor and administrator-friendly
You do realize that unifdef is included in the kernel so
it just works?
> gcc -O2 -m64 -c -o unifdef.o unifdef.c
> unifdef.c: In function 'main':
> unifdef.c:129: warning: incompatible implicit declaration of built-in
> function 'exit'
> unifdef.c:157: warning: incompatible implicit declaration of built-in
> function 'exit'
> unifdef.c:180: warning: incompatible implicit declaration of built-in
> function 'exit'
> gcc unifdef.o -o unifdef
Patches appreciated - seems a simple #include is missing.
Sam
>> However, there are three main reasons why I pledge for sunifdef
>> compatibility:
>>
>> 1. There is a project page and an inviting community
>> 2. There is HTML documentation
>> 3. They use autotools, which is distributor and administrator-friendly
autotools is, in some places, not developer friendly. A V=1 feature like
the kernel's makefile system has would be beneficial, as well as the
possibility to use PIC-compiled objects for PIE-executables (which
currently throws an error on some distros, and requires workarounds,
like the *-nolibtool files in pam_mount)
>> gcc -O2 -m64 -c -o unifdef.o unifdef.c
>> unifdef.c: In function 'main':
>> unifdef.c:129: warning: incompatible implicit declaration of built-in
>> function 'exit'
>> unifdef.c:157: warning: incompatible implicit declaration of built-in
>> function 'exit'
>> unifdef.c:180: warning: incompatible implicit declaration of built-in
>> function 'exit'
>> gcc unifdef.o -o unifdef
>Patches appreciated - seems a simple #include is missing.
#include <stdlib.h>
-`J'
--
On Thu, 05 Oct 2006 17:05:04 BST, Tony Finch said:
> already in serious trouble: for example, my unifdef was written so that I
> could understand xterm's frightening pty handling....)
Well, that code *does* warn you:
* If you think you know what all of this code is doing, you are
* probably very mistaken. There be serious and nasty dragons here.
:)