Unable to install 1.4 on Linuxmint 20.

[david allen]

configure error is

## ----------- ##
## Core tests. ##
## ----------- ##

configure:2512: error: cannot run /bin/bash ./config.sub

[Manolo]

After "git clone", file configure is absent. Typing

    make

should create it. Then, it's possible to run

   ./configure --enable-pango

for example.

[Greg Ercolano]

Should we include a fake configure in the repo that just
removes itself and runs 'make'? This comes up a lot..

[david allen]

Thanks! Everything seems to be ok now.

I don't care for the fake configure idea. I do think that since the current system is a considerable departure from tradition, README.txt should emphasize more the change.

[Greg Ercolano]

On 2020-09-09 10:37, david allen wrote:
> Thanks! Everything seems to be ok now.
>
> I don't care for the fake configure idea. I do think that since the
> current system is a considerable departure from tradition, README.txt
> should emphasize more the change.

Currently the top of the README.txt says:

----
BUILDING AND INSTALLING FLTK UNDER UNIX AND Mac OS X

In most cases you can just type "make". This will run
configure with the default (no) options and then compile
everything.
----

So that should have worked.

Curious which passages steered you wrong so we can fix them.

There are several README files, so wouldn't be surprised if any one
of them might have a passage that is dated.

Can you say how you created 'configure' in the first place
that gave the error in the OP? Then we can search for that command
in the docs to make sure it's expunged.

(The OP just shows the error, not the commands used to create configure
or the arguments it was invoked with; that could be helpful)

I think all the README files that refer to creating configure mention
running 'autogen.sh' which should have worked too, e.g. grepping the README*
files for 'auto', I found only these specific references to running the
automake tools:

README.Unix.txt:NOCONFIGURE=1 ./autogen.sh
README.macOS.md:NOCONFIGURE=1 ./autogen.sh

..as that script creates the files that were missing in the OP.

[david allen]

The command that triggered the error was

./configure --enable-cairo

I confess that this is what I was used to doing on previous installs and did not read the readme.txt carefully.

[Ian MacArthur]

On 9 Sep 2020, at 20:35, david allen wrote:
>
> The command that triggered the error was
>
> ./configure --enable-cairo
>
> I confess that this is what I was used to doing on previous installs and did not read the readme.txt carefully.

FWIW, if I’m in a hurry to set up a new checkout, what I usually do is...

Run make, then as soon as make has set up the basics and started to run configure, hit Ctrl-C.
Then run ./configure --whatever-options ; make -j6

Done...

[Greg Ercolano]

On 2020-09-09 12:35, david allen wrote:
> The command that triggered the error was
>
> ./configure --enable-cairo
>
> I confess that this is what I was used to doing on previous installs and did not read the readme.txt carefully.

OK, but hmm, I wonder how you got the "configure" in the first place
(since one doesn't come with git/svn).

In your OP it didn't say "./configure: command not found", it actually
did run a configure script that was there, but it couldn't find the .sub files,
indicating it somehow existed, but wasn't fully created.

If you don't remember that's OK, just might help us figure out something
that was the cause.

[Greg Ercolano]

On 2020-09-09 12:42, Ian MacArthur wrote:
> FWIW, if I’m in a hurry to set up a new checkout, what I usually do is...
> Run make, then as soon as make has set up the basics and started to run configure, hit Ctrl-C.

Ha, ya, I do that too after a new "git clone".
I wait until it starts configure running then ^C it and rerun it with the flags I want.

[david allen]

I didn't use git. I download and unpacked the tar.gz

[Greg Ercolano]

On 2020-09-09 13:29, david allen wrote:
> I didn't use git. I download and unpacked the tar.gz

Oh, OK, yeah, I think we include a configure with the tars,
but it should work.. I think? huh, will check.

[Greg Ercolano]

Just downloaded the recent snapshot:
https://www.fltk.org/pub/fltk/snapshots/fltk-1.4.x-20200904-a6f9388f.tar.gz

Indeed, there is a configure included, and running it fails:

./configure
configure: error: cannot run /bin/sh ./config.sub

Which is certainly confusing, and probably avoidable.

IMHO that configure we pre-package into the tar could probably could
be smarter about what to do.

FWIW, I tried extracting the tar file again, but this time immediately
replacing the existing configure script with these commands:

#!/bin/sh
mv $0 /tmp/.configure.$$ # rename ourself away to prevent recursion
make # let make handle building a real configure

..then ran it and it did create a configure script successfully.
While that's a little "hacky", it shows the concept can work.
(And should clean up after itself too)

And it could probably then run configure again with the arguments
passed to it originally to properly build the config requested.

The above would work on unices, but not unix on windows I don't think,
because Windows is a bit touchy about renaming files that are open
(like a running script), whereas unix handles it favorably.

[Albrecht Schlosser]

I use `make clean` instead. It's still pretty fast and I don't have to
watch progress and type ^C. YMMV.

[Albrecht Schlosser]

On 9/9/20 10:46 PM Greg Ercolano wrote:
> On 2020-09-09 13:31, Greg Ercolano wrote:
>> On 2020-09-09 13:29, david allen wrote:
>>> I didn't use git. I download and unpacked the tar.gz
>>
>> Oh, OK, yeah, I think we include a configure with the tars,
>> but it should work.. I think? huh, will check.
>
> Just downloaded the recent snapshot:
> https://www.fltk.org/pub/fltk/snapshots/fltk-1.4.x-20200904-a6f9388f.tar.gz
>
> Indeed, there is a configure included, and running it fails:
>
> ./configure
> configure: error: cannot run /bin/sh ./config.sub
>
> Which is certainly confusing, and probably avoidable.

Snapshot creation is a process we can modify.

I don't know why this configure script is included (maybe in an attempt
to do the same as in the dist tarball), so we have two choices:

(1) do not include the configure script
(2) add the two scripts config.guess and config.sub

The latter would probably be the better choice.

If you wanna try it, you can use the files "bundled" in our misc folder:

$ ls misc/config.*
misc/config.guess misc/config.sub

Let me know if you want me to change the snapshot process by using (1)
or (2) or not at all...

[Manolo]

I believe the weekly tar file should contain config.sub and config.guess.

They are present in the release tar files, and the error reported by the OP

does not occur if misc/config.sub and misc/config.guess are duplicated

to config.sub and config.guess.

[Albrecht Schlosser]

Done. The next snapshot (tomorrow) will include these files.

I verified that unpacking the snapshot and directly executing
'./configure --options ...' works.

@fltk-devs:

FYI: if we'd ever need a newer version of these files the correct way
would be to put them into the misc/ directory which can be done with:

$ cd misc
$ ./update_config_scripts

... check for warnings and errors, run tests ...

$ git add / commit / push

FTR: Done that as well, commit: e2a249fca99ab9.

Note: the script above uses 'wget' but you can also pull the files with
a browser (see URL's in the script).

[Greg Ercolano]

I know we had a long thread about all this years ago, and there were
reasons why it is the way it is.

IIRC, it's best if autoconf generates these files, as it can have version
specific stuff in them. I think we hit a snag once when autoconf changed
something, and our frozen copies broke it.

We keep those copies around in the misc directory as a fallback, in case
it doesn't generate them.

It's why we have these targets in the Makefile:
_______________________________
config.guess config.sub:
-automake --add-missing 2> /dev/null <-- THIS SHOULD GENERATE THE TWO FILES. IF NOT, NEXT TWO LINES DO
if [ ! -e config.sub ]; then echo NOTE: Using frozen copy of config.sub; cp misc/config.sub . ; fi
if [ ! -e config.guess ]; then echo NOTE: Using frozen copy of config.guess; cp misc/config.guess . ; fi
_______________________________

..and why 'make distclean' does this:
_______________________________
$(RM) config.guess
$(RM) config.sub
$(RM) configure
_______________________________

[imm]

FWIW (not much!) my recollection tallies with Greg, there's some reason why we didn't just "hard code" the fallback versions of these files...

The auto-generated versions were "better".

But I never understood autoconf so...

If the OP had the autoconf tools installed, it might have worked? I don't think so but am not sure.

Running make first does seem to work, since it will try to use the fallback files if the automake doesn't create them.

 But I'm not even sure about that as my systems do have autoconf, even the mingw/Windows ones.

So if we ship a pre-generated configure script, how do we know that it can find the config.[sub|guess] script?

Greg's suggestion of using a wrapper around configure might be the way to go? Anyone who runs autoconf will overwrite that anyway, and anyone who just types ./configure will (probably!) get the expected behaviour?

Or I'm missing the point entirely?

-- 
Ian
From my Fairphone FP3
   

[Albrecht Schlosser]

On 9/10/20 2:28 PM Greg Ercolano wrote:
>
> I know we had a long thread about all this years ago, and there were
> reasons why it is the way it is.

I don't remember that particular thread, but ...

> IIRC, it's best if autoconf generates these files, as it can have version
> specific stuff in them. I think we hit a snag once when autoconf changed
> something, and our frozen copies broke it.

It's not `autoconf', it's `automake' that creates these files. We do
this in the distrubution tarballs anyway, so IMHO we can (should!) also
do it in the snapshots.

> We keep those copies around in the misc directory as a fallback, in case
> it doesn't generate them.
>
> It's why we have these targets in the Makefile:
> _______________________________
> config.guess config.sub:
> -automake --add-missing 2> /dev/null <-- THIS SHOULD GENERATE THE TWO FILES. IF NOT, NEXT TWO LINES DO
> if [ ! -e config.sub ]; then echo NOTE: Using frozen copy of config.sub; cp misc/config.sub . ; fi
> if [ ! -e config.guess ]; then echo NOTE: Using frozen copy of config.guess; cp misc/config.guess . ; fi

Yep, this is well known, and most of the devs know this. However, it's a
FAQ (as you also noticed) because other users have issues with this.

The "normal" procedure with probably most distributed software is to
execute `./configure; make', but this does NOT work with our snapshots
although it works with the release tarballs. This should be "fixed".

> _______________________________
>
> ..and why 'make distclean' does this:
> _______________________________
> $(RM) config.guess
> $(RM) config.sub
> $(RM) configure
> _______________________________
>

Okay, that means: if you get to running `make' then you can also run
`make distclean' after the build or before the next build. You see also
that `make distclean' cleans *both* the configure script and the
config.* files. After that you can always run `make' *or* read the
README files. ;-)

More details: the `makesrcdist' script that creates the release tarballs
does this:

```
echo Creating configure script...
autoconf -f

echo Creating config.guess and config.sub \(ignore any other errors\)...
automake --add-missing --copy 2>/dev/null
```

So we create both the configure script and the config.* files. But we
need autoconf and automake to do this. By this we copy *arbitrary* files
(depending on the current autoconf and automake version on the build
system) into the release tarballs.

The snapshots are created on our FLTK server. The autoconf and automake
versions on the server are most likely even older than on the release
build system (typically my own Linux box because I've created most of
the latest releases).

The files misc/config.guess and misc/config.sub files can be updated
from their original sources (see links in the files and in the
update_config_files script). Hence these files should (or can, at least)
be up-to-date. They *should* always be up-to-date for release tarballs
(but this is not guaranteed, it must be done manually).



That all said, my points are:

(1) the snapshots should behave like the release tarballs

(2) the snapshots are for "normal" users that build FLTK, not for
software gurus (or devs like us)

(3) the "bundled" config.guess and config.sub files should be current
(we can update them frequently)

(4) it's a FAQ, hence we need to do "something"

[w1hkj]

  // must do shortcuts first or the scrollbar will get them...
  if (event == FL_ENTER || event == FL_LEAVE) return 1;
  if (event == FL_KEYBOARD && type() >= FL_HOLD_BROWSER) {
    void* l1 = selection_;
    void* l = l1; if (!l) l = top_; if (!l) l = item_first();
    if (l) {
      if (type()==FL_HOLD_BROWSER) {
        switch (Fl::event_key()) {
        case FL_Down:
      while ((l = item_next(l))) {
        if (item_height(l)>0) {select_only(l, when()); break;}
      }
      return 1;
        case FL_Up:
          while ((l = item_prev(l))) {
        if (item_height(l)>0) {
          select_only(l, when());
          break; // no need to test wp (return 1)
        }
      }
          return 1;
        }
      } else  {
        switch (Fl::event_key()) {
        case FL_Enter:
        case FL_KP_Enter:
          select_only(l, when() & ~FL_WHEN_ENTER_KEY);
      if (wp.deleted()) return 1;
      if (when() & FL_WHEN_ENTER_KEY) {
        set_changed();
        do_callback();
      }

The line "if (event == FL_ENTER || event == FL_LEAVE) return 1;

prohibits the execution of the later do_callback when FL_WHEN_ENTER_KEY

This prevents using the FL_Enter key in a user callback.

David

[w1hkj]

I really wanted to process ENTER, DELETE, LEFT and RIGHT keyboard events at the callback level

header file:

---

#ifndef FL_BROWSER2_
#define FL_BROWSER2_

#include <FL/Fl_Browser.H>

class Fl_Browser2 : public Fl_Browser
{
public:
    Fl_Browser2(int x, int y, int w, int h, const char* l = 0);
    int handle(int event);
};

#endif // FL_BROWSER2_

---

class implementation:

---

#include "flbrowser2.h"

Fl_Browser2::Fl_Browser2(int x, int y, int w, int h, const char* l)
: Fl_Browser(x, y, w, h, l)
{
}

int Fl_Browser2::handle(int event)
{
    int key = Fl::event_key();
    if (event == FL_KEYUP &&
        ( key == FL_Enter ||
          key == FL_Left ||
          key == FL_Right ||
          key == FL_Delete ) ) {
        do_callback();
        return 1;
    }
    return Fl_Browser::handle(event);
}

[Albrecht Schlosser]

On 9/10/20 4:43 PM w1hkj wrote:
>   // must do shortcuts first or the scrollbar will get them...

> *  if (event == FL_ENTER || event == FL_LEAVE) return 1;**

FL_ENTER and FL_LEAVE are events when the mouse enters and leaves the
widget borders, resp.

> *  if (event == FL_KEYBOARD && type() >= FL_HOLD_BROWSER) {
> [...]
> *      if (when() & FL_WHEN_ENTER_KEY) {**
> **        set_changed();**
> **        do_callback();**
> **      }*

>
> The line "if (event == FL_ENTER || event == FL_LEAVE) return 1;
>
> prohibits the execution of the later do_callback when FL_WHEN_ENTER_KEY
>
> This prevents using the FL_Enter key in a user callback.

That do_callback() is inside the condition 'if (event == FL_KEYBOARD
...)' which has nothing to do with the mouse move events mentioned
above. I don't think this is a bug.

PS: it would have been helpful to mention the file and line and the FLTK
version but I think I found it. TIA for the next time ;-)