Cross-platform open-source make system ()

headers Brandon J. Van Every | 1 Aug 2006 08:22

_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
Brandon J. Van Every wrote:
> William A. Hoffman wrote:
>> The CMAKE_BUILD_TYPE is by default empty on all UNIX/posix platforms.
>> Sort of goes back to when there was no build type for unix.  I suppose
>> the chicken project could force it to not be empty.   if empty, then do
>> a cache force to what you want.
>> At 06:51 PM 7/31/2006, Brandon J. Van Every wrote:
>>   
>>> I'm building with ccmake 2.4.2 on Cygwin.  When I do:
>>>
>>> IF(CYGWIN)
>>> MESSAGE("Build type is ${CMAKE_BUILD_TYPE}")
>>> SET_TARGET_PROPERTIES(libchicken PROPERTIES DEBUG_POSTFIX "-0")
>>> SET_TARGET_PROPERTIES(libchicken PROPERTIES RELEASE_POSTFIX "-0")
>>> SET_TARGET_PROPERTIES(libchicken PROPERTIES MINSIZEREL_POSTFIX "-0")
>>> SET_TARGET_PROPERTIES(libchicken PROPERTIES RELWITHDEBINFO_POSTFIX "-0")
>>> ENDIF(CYGWIN)
>>>
>>> I get "Build type is ".  Also the postfixes are ignored.
> As noted, postfixing doesn't appear to work at all on Cygwin.

None of the postfixes is chosen because the build type is not set to
Debug, Release, MinSizeRel, or RelWithDebInfo.  If you set the
CMAKE_BUILD_TYPE to Debug you will get the DEBUG_POSTFIX.

> Is there any way to get both cygchicken-0.dll and libchicken.dll.a ?

Not currently.  This looks like the way cygwin does library versions, so
we could make this the implementation of the VERSION or SOVERSION
property on Cygwin (where those properties are currently ignored).
Please create a feature request for this in the bug tracker.

Thanks,
-Brad

_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Brandon J. Van Every scripsit:

> CMake won't have this capability for awhile.  Therefore, I propose that 
> the -0 be removed from the ./configure build.  A flag for libtool somewhere?

Dream on.

--

-- 
John Cowan   cowan <at> ccil.org    http://ccil.org/~cowan
I come from under the hill, and under the hills and over the hills my paths
led. And through the air. I am he that walks unseen.  I am the clue-finder,
the web-cutter, the stinging fly. I was chosen for the lucky number.  --Bilbo

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Brandon J. Van Every scripsit:

> Surely, for reasons of historical compatibility, there's a way to do it?

Possibly.  But no one's going to invest the energy in figuring out how
to make autotools do that and make sure there are no other repercussions.
Autotools is *brittle*.

So: when in Rome, shoot off Roman candles.

--

-- 
I am expressing my opinion.  When my            John Cowan
honorable and gallant friend is called,         cowan <at> ccil.org
he will express his opinion.  This is           http://www.ccil.org/~cowan
the process which we call Debate.                   --Winston Churchill

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Brandon J. Van Every scripsit:

> People have legacy apps and don't have the luxury of rewriting their 
> builds.  I will wager the mechanism exists and is well-tested in the 
> field.  I bet you haven't RTFM.

All this lib- vs. cyg- stuff happens *below the radar* for people using
autotools, or indeed for people *not* using autotools.  You have to
muck around at the level of "ld" in order to change it.  Nobody
wants to do that.

And I just read the "ld" man page for the first time ever, and there's
not a word about how the "-0" gets there.

--

-- 
The Unicode Standard does not encode            John Cowan
idiosyncratic, personal, novel, or private      http://www.ccil.org/~cowan
use characters, nor does it encode logos
or graphics.                                    cowan <at> ccil.org

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Brandon J. Van Every scripsit:

> >And I just read the "ld" man page for the first time ever, and there's
> >not a word about how the "-0" gets there.
> 
> Classy.

The Cygwin man pages aren't usually Cygwin-specific, nor do they normally need to be.
There's probably just something I don't understand about ld options.  (I've never
deliberately run ld in my life -- only had various compilers run it for me.
Explicit linking went out with the PDP-11.)

Anyway, none of us needs a diatribe on how Cygwin is such a kludge.  It is
a kludge that has advantages for certain people, including me.  We now
know what to do to get it working under CMake.  That's the main point.

--

-- 
If you have ever wondered if you are in hell,         John Cowan
it has been said, then you are on a well-traveled     http://www.ccil.org/~cowan
road of spiritual inquiry.  If you are absolutely     cowan <at> ccil.org
sure you are in hell, however, then you must be
on the Cross Bronx Expressway.          --Alan Feuer, NYTimes, 2002-09-20

John Cowan wrote:
> Anyway, none of us needs a diatribe on how Cygwin is such a kludge.  It is
> a kludge that has advantages for certain people, including me.  We now
> know what to do to get it working under CMake.  That's the main point.
>   

Knock on wood.  Let's see you test what I have in Darcs, and if it holds 
up over time.

Cheers,
Brandon Van Every

Brandon J. Van Every scripsit:

> Knock on wood.  Let's see you test what I have in Darcs, and if it holds 
> up over time.

Getting there, but not quite.  The current darcs head winds up creating
the files as lib(u)chicken-0.dll.a and then creating symbolic links to
them using the name lib(u)chicken.dll.a.  That still confuses csi and
produces the nursery-too-small error.

The files need to be actually renamed.

--

-- 
John  Cowan  http://ccil.org/~cowan   cowan <at> ccil.org
'My young friend, if you do not now, immediately and instantly, pull
as hard as ever you can, it is my opinion that your acquaintance in the
large-pattern leather ulster' (and by this he meant the Crocodile) 'will
jerk you into yonder limpid stream before you can say Jack Robinson.'
        --the Bi-Coloured-Python-Rock-Snake

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Brandon J. Van Every scripsit:

> Please ensure that your /usr/local/bin and /usr/local/lib are free of 
> old exes and libraries,

I zapped all existing Chicken stuff in /usr/local by brute force
before doing "make install".

> and please also build Cygwin from scratch in an
> empty directory using CCMake.

It was empty, although I use "cmake ../darcs" to access my local darcs repository
rather than using CCMake (hard to script, CCMake is).  My darcs
directory remains pristine: I copy stuff out of it for autotools builds,
and reference it from CMake for CMake builds.

> As I said, when I do "csi -R srfi-1" I don't get any problems.

Still the same thing.  The problem arises from this hunk:

    +# CMake 2.4.3 can't produce both cygchicken-0.dll and libchicken.dll.a[_^M_][_$_]
    +# Currently Autoconf must produce the cygchicken-0.dll nomenclature,[_^M_][_$_]
    +# and that name is needed internally by the libraries for things to[_^M_][_$_]
    +# work correctly, so we can't ditch it in the source pool.  So we[_^M_][_$_]
    +# symlink it here.  This workaround courtesy of John Cowan.[_^M_][_$_]
    +IF(CYGWIN)[_^M_][_$_]
    +  INSTALL(CODE "[_^M_][_$_]
    +    EXECUTE_PROCESS(COMMAND \${CMAKE_COMMAND} -E create_symlink[_^M_][_$_]
    +      \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/lib/libchicken-0.dll.a[_^M_][_$_]
    +      \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/lib/libchicken.dll.a)[_^M_][_$_]
    +    EXECUTE_PROCESS(COMMAND \${CMAKE_COMMAND} -E create_symlink[_^M_][_$_]
    +      \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/lib/libuchicken-0.dll.a[_^M_][_$_]
    +      \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/lib/libuchicken.dll.a)[_^M_][_$_]
    +  ")[_^M_][_$_]
    +ENDIF(CYGWIN)[_^M_][_$_]
    +[_^M_][_$_]

Note that you are doing create_symlink.  By my reading of the situation,
you need to be doing copy followed by remove.  Remember that symlinks are
interpreted by Cygwin's library, so Windows (which is doing the dynamic
loading) is exposed to the underlying name "lib(u)chicken-0.dll".

> BTW what Cygwin mirror did you use to obtain CMake 2.4.3 ?  I haven't 
> seen it on the mirrors I've tried.

http://sourceware.tds.mirrors.net, the fastest and best Cygwin (and
Sunfreeware, for those who care) mirror out there.

--

-- 
You escaped them by the will-death              John Cowan
and the Way of the Black Wheel.                 cowan <at> ccil.org
I could not.  --Great-Souled Sam                http://www.ccil.org/~cowan

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Brandon J. Van Every scripsit:

> I can't account for build behavior with plain cmake, sans ccmake.  

Okay, I'm building with ccmake from now on.

> But if you just run a cmake from the command line, perhaps your paths
> run the wrong cmake?

No.  My path is set up so that the Cygwin directories preceded the
Windows directories, always.  In any case, I don't have native cmake on
the system at all.

> I assume you do this from a Cygwin shell, yes?  Just sanity checking.

Yes.

> Since it works on my system, our systems are clearly different.  Are all 
> your Cygwin installations recent?  I grabbed the latest greatest 1..2 
> months ago, and I unwittingly just updated various tools while 
> downloading CMake 2.4.3.  In particular here's my GCC:
> 
> Brandon J. Van Every <at> kahlo ~
> $ gcc --version
> gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)

We have the same gcc, yes.  I update Cygwin every few days, and
specifically did so yesterday and today.

> Another possibility is my Windows 2000 SP4 + Platform SDK + environment 
> + paths has something useful in it that your system doesn't have.  What 
> Windows are you using?  I wonder if there are any Cygwin symlink bugs on 
> your system.

I'm using Windows XP SP2, no MinGW, no Platform SDK.

> I wish I knew which was more consequential, a symlink or a rename.  Both 
> could be problematic.

The fact is that when I remove your symbolic links and rename the
underlying files by hand, everything works fine.  And when I patch lines
1119 and 1122 of CMakeLists.txt to say "copy" instead of "create_symlink",
everything works fine.  (I didn't bother adding a "remove", as the extra
files are harmless.)  But when I don't do these things, "csi -R srfi-1"
doesn't work.  And that is just as true whether I run cmake or ccmake;
the process is doing the same thing in either case.

Try it my way on your system.  If it works for you and it works for me,
that sounds good to me.  Here's the post-install script I'm using:

#!/bin/sh
cd /usr/local/lib
rm libchicken.dll.a
rm libuchicken.dll.a
mv libchicken-0.dll.a libchicken.dll.a
mv libuchicken-0.dll.a libchicken.dll.a

I also recommend running the following brute force "zap-chicken" script
after "make" and before "make install", which makes very sure there is
nothing lying around from earlier Chicken builds:

#!/bin/sh
cd /usr/local/bin
rm -rf *chicken* cs[ic]*
cd /usr/local/lib
rm -rf *chicken*
cd /usr/local/include
rm -rf *chicken*
cd /usr/local/man/man1
rm -rf *chicken* cs[ic]*
cd /usr/local/share
rm -rf chicken

I'm also sending you the patch with "darcs send".

--

-- 
John Cowan          http://www.ccil.org/~cowan        cowan <at> ccil.org
To say that Bilbo's breath was taken away is no description at all.  There are
no words left to express his staggerment, since Men changed the language that
they learned of elves in the days when all the world was wonderful. --The Hobbit

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Brandon J. Van Every scripsit:

> If symlinks are supposed to work on your system, but don't, then I want 
> to know why.  If symlinks aren't supposed to work on my system, but do, 
> I want to know why.  Open source is about giving the right bug report to 
> someone.  Perhaps your method will prove to be a workaround for a 
> symlink bug.  If so, we'll use it, but it'll be marked as a workaround, 
> to be changed or removed when things get better.

But why symlinks at all?  The files named "lib(u)chicken-0.dll.a" just
aren't what *anyone* uses in Cygwin or otherwise, so there is no point
in keeping them.  Do the rename (i.e. copy+delete) to arrange for the
file to have the correct name.

FWIU, the next version of CMake will do the Right Thing on Cygwin:
cygfoo-0.dll in $PREFIX/bin, libfoo.dll.a in $PREFIX/lib.  That's what
we should emulate.

> I have a sinking feeling that all these approaches are going to prove to 
> be wrong in the long run.  That really, getting down to the level of ld 
> is what's needed.

*shrug*

I'm not a big fan of "sinking feelings" without evidence.

> Do you mean, you're sending it to the Chicken repository?  That wouldn't 
> be very useful to me.  I don't put things into the Chicken repository 
> until I've vetted them locally in my own repository.  I'm not very 
> familiar with "darcs send."  If you can send it as an e-mail to me, I'll 
> figure out how it works.

Okay, here's what "darcs diff" says:

==============cut here===============
1116c1116
< # symlink it here.  This workaround courtesy of John Cowan.
---
> # copy it here.  This workaround courtesy of John Cowan.
1119c1119
<     EXECUTE_PROCESS(COMMAND \${CMAKE_COMMAND} -E create_symlink
---
>     EXECUTE_PROCESS(COMMAND \${CMAKE_COMMAND} -E copy
1122c1122,1124
<     EXECUTE_PROCESS(COMMAND \${CMAKE_COMMAND} -E create_symlink
---
>     EXECUTE_PROCESS(COMMAND \${CMAKE_COMMAND} -E remove
>       \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/lib/libchicken-0.dll.a)
>     EXECUTE_PROCESS(COMMAND \${CMAKE_COMMAND} -E copy
1124a1127,1128
>     EXECUTE_PROCESS(COMMAND \${CMAKE_COMMAND} -E remove
>       \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/lib/libuchicken-0.dll.a)
==============cut here===============

This approach is very simple, no more of a kludge than what you have,
and *works*, *works*, *works*.

--

-- 
If you have ever wondered if you are in hell,         John Cowan
it has been said, then you are on a well-traveled     http://www.ccil.org/~cowan
road of spiritual inquiry.  If you are absolutely     cowan <at> ccil.org
sure you are in hell, however, then you must be
on the Cross Bronx Expressway.          --Alan Feuer, NYTimes, 2002-09-20

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Brandon J. Van Every scripsit:

> At present, so does mine, on my box.  I'm going to refrain from 
> discussing this further until I've minimized my environment.  Then we'll 
> know whether my MinGW tools or Platform SDK was really doing the work.

Okay, time for me to eat crow.

The cause of the crashes was that I was in my cmake directory while trying
to test "csi -R srfi-1", *not* because the symbolic links don't work.
They do work.

But if you are in the build directory, you get into trouble because
Windows gets confused and installs DLLs from the current directory first,
even though the current directory is not on the path.

Doing "csi -R srfi" from any other directory is not a problem.  So after
I changed to my home directory or to /usr/local/lib to make the changes,
everything was fine, though not because of those changes, simply because
I was no longer in the build directory.  Sorry about all that.

CMake on Cygwin works!

--

-- 
You know, you haven't stopped talking           John Cowan
since I came here. You must have been           http://www.ccil.org/~cowan
vaccinated with a phonograph needle.            cowan <at> ccil.org
        --Rufus T. Firefly

Re: Cygwin ccmake 2.4.2 CMAKE_BUILD_TYPE empty

Re: Cygwin ccmake 2.4.2 CMAKE_BUILD_TYPE empty

Re: Cygwin ccmake 2.4.2 CMAKE_BUILD_TYPE empty

CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

Re: CMake cygwin can't do -0

CMake on Cygwin really, really works now