New release of JWM (Joe Window Manager)

fredvs

fredvs

Hello.

There are important new features in JWM (https://github.com/joewing/jwm).

I have try to compile the source with automake and autoconfigure, like explained in README.md, but sadly, it seems to work only for Linux.

How must I do to re-compile JMW for FreeBSD ?
Or better (and easier), is it a plan to update JWM in FreeBSD port ?
Thanks.

Fre;D
 
Last edited:
Hello.

Thanks for the lot (as usual) answers.
Ok, I was able to compile it from Github.

But I do not want to annoy you (as usual) to explain how I did.

Fre;D
 
In a case like this, you're better off filing a bug or sometimes, even emailing the port maintainer.
It is also good to explain how you did it, even if no one answered. You might have gotten more answers with a better subject line, like trying to compile JWM from source. As it was, it looked like an announcement of a new release, and those who don't use it didn't bother to look.

Anyway, if you do have time, I'm sure that someone will, sooner or later, find the solution useful.
 
Here how to compile JWM from Github source.

-1) Download last source from here https://github.com/joewing/jwm (Click on [Clone or Download]).
Unzip it. You will have a new directory: /jmw-master

-2) Install (with sudo pkg install thepackage):
. gcc, gcc-ecj, gmp, m4, mpc, mpfr, autoconf, autoconf-wrapper, automake, automake-wrapper.

-3) Check if in your root-system /sys is linked with directory of C system-headers.
If the link /sys is broken, create that symlink:
ln -s /usr/include/sys /usr/src/sys

-4) Test if gcc is working: create a new file with your favorite text editor and paste this:

Code: 
    main()
{
printf("hello world ");
}

Save it as hello.c then test it with:
gcc /directory/of/theprog/hello.c

If you get a a.out executable, continue next step.


-5) Compile JWM:
cd /directory/of/jmw-master
./autogen.sh
./configure
make

-6) jmw executable should be in /jmw-master/src

Fre;D
 
fredvs said:
-3) Check if in your root-system /sys is linked with directory of C system-headers.
If the link /sys is broken, create that symlink:
ln -s /usr/include/sys /usr/src/sys
Click to expand...

This is not correct, you are going to broke something else, in example ports that require system src in /sys->/usr/src/sys.
 
fredvs said:
What do you propose then to make gcc work if some program needs /sys ?
Did you read that topic (last posts)? https://forums.freebsd.org/threads/55369/
Click to expand...
Yes I read that thread too.
It isn't that the program require /sys, it is that require some header file that in Linux is in /sys ...

Usually you can force gcc to look elsewhere for non standard include dirs, or like it seems the case, for include dirs different in FreeBSD compared to Linux,;

I guess you can check for 'configure' options, depending on the required include dirs, something like:
./configure --sys-headers=/usr/include/..."
 
ASX : Yep, finally a positive and useful answer. Many thanks.

@ All FreeBSD team: Linux is not your enemy. And even if the Linuxator was a present of Google (is it bad ?), it is a huge plus to be able to compile Linux source and have FreeBSD app working (issuing from Linux source) and Linux apps too via the Linuxlator.

Fre;D
 
Last edited:
marino@ said:
come again now?
Click to expand...
No, no, but IMO, all what comes from Linux is not necessary bad.

And why not help the developers (who are not married with Linux nor FreeBSD nor nothing) to make their programs easy to compile, even for FreeBSD.

[EDIT] I can not imagine that only what is in official FreeBSD port has the right to be compilable.

The trick of ASX could be one of the advices to "Easily make your source compilable on FreeBSD".

Fre;D
 
<sigh>

I think it's pretty obvious you've never tried approaching developers of linux-only software.
First, there's a really good chance that the reason the s/w is linux only is because the developers aren't very good and they don't know how to write portable software. While some appreciate assistance in making it more portable, it's been more common in my experience that they don't want it. They'll tell you to work around it or just move to linux where all the cool people are.

I'm not even sure why you believe the onus is on freebsd developers to take the initiative to fix these programs.
 
marino@ said:
<sigh>

I think it's pretty obvious you've never tried approaching developers of linux-only software.
First, there's a really good chance that the reason the s/w is linux only is because the developers aren't very good and they don't know how to write portable software. While some appreciate assistance in making it more portable, it's been more common in my experience that they don't want it. They'll tell you to work around it or just move to linux where all the cool people are.

I'm not even sure why you believe the onus is on freebsd developers to take the initiative to fix these programs.
Click to expand...

No, sorry, but IMO you are wrong.
Linux developers will certainly be open to make their source compilable on FreeBSD.
But, of course, if they are not obliged (like now) to loose all their hair and their time.

PS: I do not have that problem, I do not develop in C any more (I am tired about the C-compiler war).
I use fpc (free pascal compiler) and develop in Pascal, that has no problem of compatibility and works on nearly all os that exist. And the new Pascal object permits all (even more) than C or C++.

PS2: But to make C source compilable on different os ==> WHAT A HELL.

Fre;D
 
ASX said:
Yes I read that thread too.
It isn't that the program require /sys, it is that require some header file that in Linux is in /sys ...

Usually you can force gcc to look elsewhere for non standard include dirs, or like it seems the case, for include dirs different in FreeBSD compared to Linux,;

I guess you can check for 'configure' options, depending on the required include dirs, something like:
./configure --sys-headers=/usr/include/..."
Click to expand...
Sorry to come back.

JWM code uses autoconfig and automake.

Would it not must be the work of autoconfig and automake to setup sys-headers=/usr/include/ automatic ?

Fre;D
 
It's just more compatible with FreeBSD's license. It allows more freedom to modify code and remove redundant code, that is a problem in much of GPL. It usually allows for more improvements of code, without having to rely on limited available choices. For personal end use alone, without potential improvements in code, there's not much difference. For business use, and their customers it does a lot.
 
fredvs said:
Would it not the be the work of autoconfig and automake to setup sys-headers=/usr/include/ automatic ?
Click to expand...

I suppose yes, they should, but they still require some hint, usually provided from the developers, about what to check for.

Honestly I'm not a fan of these tools, in my opinion they are actually used and abused, and that very often will result in a cryptic errors ... "undefined AC_MACRO ....", later solved by adding 'pkg-config' or something else, totally unrelated to the error.
You (I did) will spend lot of time looking for what is wrong, without a real hint about what is going on.
So, I always used them passively, never actively, my answer may reflect my limited knowledge of them.

fredvs said:
PS: I do not have that problem, I do not develop in C any more (I am tired about the C-compiler war).
I use fpc (free pascal compiler) and develop in Pascal, that has no problem of compatibility and works on nearly all os that exist. And the new Pascal object permits all (even more) than C or C++.
Click to expand...

Porting software it is not limited to language differences, and C is implemented very consistently across different compilers/OSes, and require deep knowledge of both the originate OS and the target OS ... I could mention just as an example a simple app requiring to access Linux-udev events or FreeBSD devd events: in Linux your program will make use of libudev, in FreeBSD will make use of a socket, there is no way a language itself can overcome this type of differences, autoconf/automake will not help here, same for "fpc".

As a result, because the knowledge of different OSes is not so widely diffused, software is often written in a non portable way, even if portability was desired from the original author, same when using tools like autoconf/automake.
 
ASX said:
I suppose yes, they should,
Click to expand...

Ha, finally we have found the guilty ;-)
IMO, a basic work of autoconf would be to find not only the location of the compilers and some libraries but also he must know that, with FreeBSD, the source of system-header are in /usr/include/sys.

Many thanks ASX

Fre;D
 
ASX said:
same for "fpc".
Click to expand...

No, fpc is different and take care about developers. No automake or autoconf needed, fpc exists for many (all) os and works, out of the box, with same code, for each os.

Fred;D
 
ASX@ fredvs doesn't get it so you might as well let him keep living in his own little world. :)
(This comes from somebody that has written a lot of code with FPC in production environments)
 
marino@ said:
ASX@ fredvs doesn't get it so you might as well let him keep living in his own little world. :)
(This comes from somebody that has written a lot of code with FPC in production environments)
Click to expand...
Wow, thanks for that constructive answer.
By the way, if you are a FPC developer, it is sad that you did not see that FPC code is much more portable to other os than C code.

Have good days in your big closed world.

Fre;D
 
I created the port of FPC to DragonFly BSD. If there's anybody here that understands pascal, C, and portability it's me.
Your first problem is that you either misunderstood ASX or you ignored his point. He was talking about portability issues *independent* of the language, and you completely ignored that.
Second, you keep referring to your opinion as if that somehow trumps experience. It doesn't.
Third, what does "closed" have to do with "portability"?
Fourth: There's no FPC easily available on many platforms. That means ZERO portability for those.

I have also ported and still maintain Ada compilers for several platforms and if you want to get into portability contests, Ada beats them both.
 
  • Thanks
Reactions: ASX
marino@ said:
I created the port of FPC to DragonFly BSD. If there's anybody here that understands pascal, C, and portability it's me.
Your first problem is that you either misunderstood ASX or you ignored his point. He was talking about portability issues *independent* of the language, and you completely ignored that.
Second, you keep referring to your opinion as if that somehow trumps experience. It doesn't.
Third, what does "closed" have to do with "portability"?
Fourth: There's no FPC easily available on many platforms. That means ZERO portability for those.

I have also ported and still maintain Ada compilers for several platforms and if you want to get into portability contests, Ada beats them both.
Click to expand...

OK, you are in bad mood today.
Take a rust and I will answer to your 3 first problems.
...
> Fourth: There's no FPC easily available on many platforms. That means ZERO portability for those.

On official download directory of fpc:

_______________________________________________________________________________________

And could please take a look at the video polYdev (FreeBSD64) in action, using 5 different fpc compilers, installed out-of-the-box from the download site.

Fre;D



 
You didn't answer diddly squat.
I was talking about platforms that aren't supported, not the ones that are.
Where's NetBSD on that list? OpenBSD? 100 different linuxes? Are you sure the solaris packages can be installed? what about illumos'?
what about FreeBSD ARMv7? Other FreeBSD tiers?

All you did is expose that you really don't know much about this stuff.
 
JWM is not Linux specific anymore, it is also not bloated like other window managers. There is an interest in it for FreeBSD, or especially desktop variants.

I suggest trying LLVM/Clang to compile it. I don't see much responsibility for FreeBSD to troubleshoot GCC (because even if successful, it will go right back to using ambiguous coding, for its mission), except where people want to to make programs that require it work. If there is a major problem for GCC, that fixing it will benefit many operating systems, the developers of that program will do it, because it fixes it for their choice OS.
 
You must log in or register to reply here.
Back
Top