Re: Building frozen pre-1.0.4

From: Henning Meier-Geinitz (hmg-ml@gmx.de)
Date: Sun Dec 17 2000 - 07:00:19 PST

  • Next message: Paul Floyd: "Re: Building frozen pre-1.0.4"

    Hi,

    On Sun, Dec 17, 2000 at 12:11:01PM +0100, Paul Floyd wrote:
    > I've just been building the latest code in pre-1.0.4 under OS/2
    >
    > To put it into context, it took me about 4 hours just to get it to
    > compile. It'll probably take even longer to get it to work.

    I'm not surprised. We haven't gotten any patches for OS/2 for a long
    time.

    > Here's my list of things that are broken.
    >
    > PATH_MAX gets used when it isn't defined. Perhaps it should be in
    > config.h.in?

    Most backends use this:

    #ifndef PATH_MAX
    # define PATH_MAX 1024
    #endif

    Where does it break? Does it help to add these lines to the files?
     
    > sharp.c and nec.c use shm.c, which is only available on System V (and
    > clone) platforms.

    We can detect the availibility of shm.h in configure and check in
    nec.c/sharp.c. If both backends depend on shm (no alternative), they
    can be excluded from compilation. Is OS/2 using the normal configure
    script?

    > nec.c still includes constants defined in sharp.h
    > (though they are #defined out by default).

    Could you go into more detail here?

    > Tell me, is SANE supposed to
    > be cross platform or is it supposed to be Linux proprietary-style code?

    SANE is supposed to run on any Unix platform. It's tested on Linux,
    FreeBSD, Solaris, AIX and Irix. We will be happy to make it run on all
    platforms but someone must test them and send patches. I can only test
    the mentioned platforms.

    Concerning OS/2: We can include patches for OS/2 (after 1.0.4 is
    released) if they don't disrupt compilation for Unix. But the patches
    must be done by OS/2 users. I have asked for OS/2 comments more than
    once and nobody wanted to do the work. We (the Unix developers) can't
    do it--it must be done by persons using OS/2.

    > I can't tell whether the brute force altering of the #defines to allow
    > me to compile has any impact as I don't have an NEC or Sharp scanner.

    What defines exactly? If some backends don't compile, just disable
    them in the Makefile for now.

    > By default, the warning options have changed, and this wouldn't compile
    > sanei_scsi.c (the structure param around line 2900).

    Are you talking about the warning parameters given to gcc? These have
    been set to --disable-warnings by default for the realease. This
    shouldn't break anything. If disabling warnings break compilation
    something else must be broken. Please send the output of make / of the
    compiler.

    What do you mean by "structure parameter"?

    > The date of the snapscan code is old. The date of the files on
    > sourceforge is November 2000, the included snapscan files are from
    > August 2000.

    Yes, that's correct. The new Snapscan backend can be included into
    SANE after the release of 1.0.4 as discussed on this mailing list.

    Thanks for your tests.

    Bye,
      Henning

    --
    Source code, list archive, and docs: http://www.mostang.com/sane/
    To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
    



    This archive was generated by hypermail 2b29 : Sun Dec 17 2000 - 09:00:42 PST