[Ecls-list] Build system on Cygwin

[Jean-Pierre Flori]

2012/8/17 Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com>:
> On Fri, Aug 17, 2012 at 12:46 PM, Jean-Pierre Flori <jpflori at gmail.com>
> wrote:
>>
>> On Cygwin at least, when the linker is given the -lecl flag, it will
>> look for files in PATH in a certain order.
>> First libecl.dll.a, then ..., then cygecl.dll, then ... then ecl.dll
>> IIRC [...]
>>
>> So if we only have cygecl.dll every thing should be fine, provided
>> xxx/bin is in PATH (or wherever it was installed).
>
>
> That is not a problem: it is already a requirement.
>
>>
>> From what I understand, the linking process will be somehow slower,
>
>
> There's nothing that prevents ECL from using import libraries, but the fact
> that Lisp users expect only one file to be generated by COMPILE-FILE, not
> two. However, in the case of full DLLs (as with ecl.dll) we could afford to
> use an import library.
If youre really worried with producing two files, we could do it in two steps.
First generate cygecl.dll alone and then used dlltool to produce
libecl.dll.a (potentially from libecl.def) from cygecl.dll.
>
>>
>> As there seems to be a free version floating around, I think I'll give
>> it a try... What pieces of the ECL suite do actually link to ecl.dll?
>
>
> The executable itself plus all compiled files (*.fas). When a Lisp user
> compiles a library, such as those distributed with quicklisp, or Maxima, or
> the modules that ECL builds (ecl-curl, asdf, etc), they have to be linked
> with the library.
>
>>
>> Oh, and a final remark, on Cygwin at least, the dllimport magic is broken.
>> The dllexport stuff gets defined in the headers at build time because
>> "cygwin" is defined by the build system.
>> But when included from another project (let's say Sage :), the
>> dllimport is included only if "cygwin" is defined... which has no
>> reason to be.
>> The easiest fix I found was to define "cygwin" when "__CYGWIN__" is
>> (and that gcc does define on Cygwin).
>
>
> We would have to fix the ECL headers.
I'll open a bug on sourceforge and provide a patch for this week end
hopefully, unless you prefer to do it.
And in addition rather than the fix above, wouldn't it be better to
only test on one of the above macro?
At ECL build time both are available: cygwin thanks to the configure
magic, and __CYGWIN__ if a sensible compiler is used.
When building against ECL, only __CYGWIN__ will be (or nothing if
using a mean compiler).
Ok this only matters in config.h, but...
Or you could imagine that " "define some_macro_for_cygwin" is written
in config.h at configure time if cygwin is defined.
This would let programs build against ECL with compiler not defining __CYGWIN__.
And in fact that's not really clever, because if you compile from
another environment and link to ecl which links to cygwin, you might
not want to directly link to cygwin...
So all of this looks complicated, whereas only using __CYGWIN__ at ECL
build time and in config.h seems fine as well.

By the way, this is also true for MinGW32, in the source code both tests on
mingw32 (which is only available at build time, defined by configure)
and __MINGW32__ are used.

>
> Juanjo
>
> --
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
> http://juanjose.garciaripoll.googlepages.com



-- 
Jean-Pierre Flori