Re: [Mingw-cross-env-list] Vmime portability fix for FreeBSD

[Mark Brand]

> Mark, do you think it would be a good idea to
>
> (1) include that patch snippet into the new
>
>         src/vmime-2-fixes.patch
>
>     patch?
>   

The "fixes" patch is gone since we moved up to r533.

Tony's submitted his patch to vmime and I voted for it.  Once it's
accepted, we can remove the "sed" patch for this from vmime.mk.

> (2) Also, what's about moving other SED actions into that patch
>     and to proprose them to upstream?
>
>         $(SED) "s/'-ansi', //;"                        -i '$(1)/SConstruct'
>         $(SED) "s/'-pedantic', //;"                    -i '$(1)/SConstruct'
>   

These might not be clear-cut cases. My impression is that -ansi and
-pedantic cause trouble specifically for mingw, but I don't actually
know much about the issues involved.

A proper patch for this would probably be messier than this sed-hack
since it would have be sensitive to whether the target platform is mingw.

>         $(SED) 's/^sh libtool/sh libtool --tag=CXX/g;' -i '$(1)/SConstruct'
>   

This has been removed. It was an attempt to make the "global
constructor" detection work, but r533 deals with this issue in a
different way.

> (3) And is it possible to make SConstruct use the right pkg-config
>     tool, such that the following SED action will become unnecessary?
>
>         $(SED) 's/pkg-config/$(TARGET)-pkg-config/g;'  -i '$(1)/SConstruct'
>   

We could do that, but there is not much point. After the next vmime
release, we won't need to run SConstruct anymore. These references have
nothing to do with the configure.in that is produced.

> (4) I'm also thinking about removing the following lines from src/vmime.mk:
>
>         $(SED) 's,libtoolize ,$(LIBTOOLIZE) ,' -i '$(1)'/bootstrap
>         cd '$(1)' && ./bootstrap
>
>     These lines seem to be unnecessary because the autotools are already
>     called before, by the "scons autotools" command:
>
>         cd '$(1)' && scons autotools \
>              prefix='$(PREFIX)/$(TARGET)' \
>              target='$(TARGET)' \
>              sendmail_path=/sbin/sendmail
>
>   

Won't they still be needed once we stop calling scons?

> (4b) Last but not least, does that command need an argument for
>      libtoolize such as the following?
>
>         cd '$(1)' && scons autotools \
>             ...
>             libtoolize='$(LIBTOOLIZE)'
>
>      Or does it automatically check for "libtoolize vs. glibtoolize"?
>
>
>   

I think all we need to worry about is whether we get a good configure.in
from SConstruct. Hopefully, we won't have to worry about this for long.

-Mark