# New release of JWM (Joe Window Manager)



## fredvs (Oct 1, 2016)

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


----------



## fredvs (Oct 2, 2016)

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


----------



## scottro (Oct 2, 2016)

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.


----------



## fredvs (Oct 4, 2016)

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:


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


----------



## ASX (Oct 4, 2016)

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



This is not correct, you are going to broke something else, in example ports that require system src in /sys->/usr/src/sys.


----------



## fredvs (Oct 4, 2016)

ASX said:


> This is not correct, you are going to broke something else, in example ports that require system src in /sys->/usr/src/sys.


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/

Fre;D


----------



## ASX (Oct 4, 2016)

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/


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/..."`


----------



## fredvs (Oct 4, 2016)

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


----------



## marino (Oct 4, 2016)

fredvs said:


> And even if the Linuxator was a present of Google



come again now?


----------



## fredvs (Oct 4, 2016)

marino@ said:


> come again now?


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


----------



## marino (Oct 4, 2016)

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


----------



## fredvs (Oct 4, 2016)

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



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


----------



## sidetone (Oct 4, 2016)

Hey, JWM switched to an MIT license.


----------



## fredvs (Oct 4, 2016)

sidetone said:


> Hey, JWM switched to an MIT license.


Ha, ok.
By the way, I am not lawyer, was does it change ?


----------



## fredvs (Oct 4, 2016)

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


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


----------



## sidetone (Oct 4, 2016)

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.


----------



## ASX (Oct 5, 2016)

fredvs said:


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



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



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


----------



## fredvs (Oct 5, 2016)

ASX said:


> I suppose yes, they should,



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


----------



## fredvs (Oct 6, 2016)

ASX said:


> same for "fpc".



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


----------



## marino (Oct 6, 2016)

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)


----------



## fredvs (Oct 7, 2016)

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)


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


----------



## marino (Oct 7, 2016)

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.


----------



## fredvs (Oct 7, 2016)

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



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:


ARM
Game Boy Advance
Nintendo DS
Linux
Windows CE
Android

Intel/i386
Dos (GO32v2 extender)
FreeBSD
Linux
Mac OS X (and cross-compilers for PowerPC(64)/Mac OS X, iOS & iPhoneSimulator, JVM/Java and JVM/Android).
Haiku
OS/2 (and eComStation)
Solaris
Windows 32-bit (and a cross-compiler ARM/MIPS/i386-Android)
Android

PowerPC
Linux
Mac OS X
Nintendo Wii

PowerPC64
Linux
Mac OS X

SPARC
Linux
Solaris

AMD64/Intel 64/x86_64
FreeBSD
Linux
Solaris
Windows 64-bit

i8086
MS-DOS

MIPS
Android

_______________________________________________________________________________________

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
_


_


----------



## marino (Oct 7, 2016)

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.


----------



## sidetone (Oct 9, 2016)

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.


----------



## fredvs (Oct 9, 2016)

sidetone said:


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



Hello sidetone and thanks for your excellent advice.
Of course I am open to use `LLVM` vs `GCC`.
And `JWM` is a perfect example.

Could you, please, give the step-by-step way (like I did for `GCC`) to compile `JWM` GitHub-source with LLVM37 ?

Many thanks.

Fre;D


----------



## sidetone (Oct 10, 2016)

For all of the ports, it's in /etc/make.conf, to choose which compiler and version. It's probably in the handbook. It should use the compiler that's existing with your system.

To go by Gitfile, use the porter's handbook. https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ . The same subject is repeated with one part giving better detail. Copy the port's Makefile of JWM, to its own custom directory to examine and edit it. I don't see automake or autoconf in it's Makefile. First remove the existing JWM package before compiling.

Which features are you trying to activate? Because the latest version of JWM in ports is the new version 2.3.6. You can ask the maintainer to include an option for what you're trying to use, after you've tested it.

* edit - its in the port's Makefile to choose which complier and version to use for individual ports.


----------



## DutchDaemon (Oct 10, 2016)

Gentlemen (fredvs, marino@), there's nothing wrong with a lively debate, but can we stop short of the _inside_ boundary of civility? Thanks.


----------



## fredvs (Oct 10, 2016)

sidetone said:


> I don't see automake or autoconf in it's Makefile.



They are in the "`autogen.sh`" script and are needed to create the Makefile and configure scripts.



sidetone said:


> Which features are you trying to activate? Because the latest version of JWM in ports is the new version 2.3.6. You can ask the maintainer to include an option for what you're trying to use, after you've tested it.



Take a look at https://github.com/joewing/jwm
There are new commits and Joe is busy to make JWM voice-asssistable.
I will be one of his tester.

Please, I do not want to depend of the pkg maintainer to have the permission to compile original source.


Fre;D


----------



## fredvs (Oct 10, 2016)

DutchDaemon said:


> Gentlemen (fredvs, marino@), there's nothing wrong with a lively debate, but can we stop short of the _inside_ boundary of civility? Thanks.


I think that I stay polite, but when somebody ask to not answer to my questions and that I have to stay in my "little world", it is aggressive.

Fre;D


----------



## sidetone (Oct 10, 2016)

Read my last post again. You can copy jwm's Makefile from ports to a custom folder, edit it, and compile it, after removing the jwm package.

Once you compile and test it on your own, you can inform the maintainer what works.

The Porters Handbook and other existing FreeBSD documentation should give some pointers for compiling on your own.


----------



## fredvs (Oct 11, 2016)

sidetone said:


> Read my last post again. You can copy jwm's Makefile from ports to a custom folder, edit it, and compile it, after removing the jwm package.
> 
> Once you compile and test it on your own, you can inform the maintainer what works.
> 
> The Porters Handbook and other existing FreeBSD documentation should give some pointers for compiling on your own.



Thanks sidetone.

But I will tell you all.

I already tried to compile JWM original code with LLVM37 ( with `./configure CC=LLVM37 CXX=LLVM37` )
Compilation failed because "error in syntax" (because not 100% compatible C code) . And then the original code must be changed.

But, ok, I will take a look at the Makefile from ports. If it is only the Makefile that must be changed, ok.

Fre;D


----------

