[sane-devel] How best to distribute the m4 directory?

[Olaf Meeuwissen]

Chris Bagwell <chris at cnpbagwell.com> writes:

> Ah yes, I hadn't thought about looking at iscan source code yet;
> although I'd recently installed the binary to play with on my new
> Epson Artisan 800.

FTR, supported as of iscan-2.14.0.

> I just looked at iscan now and it is indeed a great starting point
> for this task and I like the diff approach to ltmain.sh

WRT the iscan build system, please note that I could afford myself the
luxury of dealing with only a _single_ backend and didn't have to deal
with much documentation.  In addition, I could just drop whatever make
target I didn't use.

Also, when I did the work I believe we were still using autoconf-2.13
and automake-1.4.  Both have changed a lot in the mean-time and though
I've tried to keep iscan up-to-date I haven't really looked at
whatever benefits the newer autotools have to offer.

> Olaf, if you have suggestions on how to proceed then please let me
> know.  Based on your past work, I'm guessing you could whip this up
> pretty fast... I also don't mind diving right in and know I can get
> it completed soon as well.  I can provide some draft patches soon.

I don't think we will be able to replace the whole build system in one
fell swoop, let alone without breaking anything.  So, I guess doing
this on a branch in CVS is the only sane approach.

# I don't have SSH access to the outside at work ... that makes using
# CVS very awkward, to say the least.  Even the daily snapshots are of
# zero use as they follow the trunk.

As to whipping this up pretty fast, it's been a while so I need a bit
of a refresher on the SANE build system part.

> I don't think we can split the work very well but definitely can use
> each other to test on variety of autotool versions (those issue tend
> to be limited to configure.ac though).

Indeed, it is a bit difficult to split the work, but we could do it a
directory at a time.  Start with the top-level without descending the
source tree and then add in subdirectories as you go.  That way, each
of us can do a different directory and not step on the other's toes,
so to speak.  What you posted to the list seems like a reasonable
starting point for the top-level directory (after you add a license
blurb).  We should probably focus on getting the regular build for the
binary parts to work ASAP, then deal with the "support" targets for
documentation and website info and leave the "niceties" like
build-time options to select specific backends and such for later.

Of course, we should also switch sane-frontends over.

More detailed discussion we should probably take off-list.  What do
you think?

> Chris
>
> m. allan noah wrote:
>> Sounds good. Chris- can you coordinate with Olaf to do something
>> similar with sane's copy of ltmain?
>>
>> allan
>>
>> On Mon, Jan 12, 2009 at 7:43 PM, Olaf Meeuwissen
>> <olaf.meeuwissen at avasys.jp> wrote:
>>   
>>> "m. allan noah" <kitno455 at gmail.com> writes:
>>>
>>>     
>>>> [switching sane build system to autotools]
>>>> You (and others on this list) have more experience with these tools
>>>> than I, so I am willing to defer to your judgement. But watch out for
>>>> the sane-specific copy of libtool. We have some hacks in there to make
>>>> each sane backend's .so export symbols so that it can be linked
>>>> directly.
>>>>       
>>> The iscan sources include these changes as a patch to ltmain.sh and
>>> uses a little bootstrap script to apply it.
>>>
>>> I'd be happy to help out with converting the SANE build system to an
>>> autotool based one.  FWIW, iscan started out with SANE's build system
>>> and I've converted it to use autotools a few years ago.

Hope this helps,
-- 
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962               Help support software freedom
                 http://www.fsf.org/jf?referrer=1962