Bugs item #3494982, was opened at 2012-02-27 04:12
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3494982&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: compile or build problem
Group: wrong behaviour
>Status: Pending
>Resolution: Later
Priority: 5
Private: No
Submitted By: theret (theret)
Assigned to: Daniel Stenberg (bagder)
Summary: CMake fails with sources from github

Initial Comment:
OS: any
CMake: any
cURL: current development sources from github

CMake fails with:

CMake Error at src/CMakeLists.txt:18 (add_executable):
  Cannot find source file:

    config-win32.h

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

The failing line is:

${CMAKE_SOURCE_DIR}/src/CMakeLists.txt:18:
add_executable(
  ${EXE_NAME}
  ${curl_SOURCES}
  )

curl_SOURCES is defined in ${CMAKE_BINARY_DIR}/src/Makefile.inc.cmake:
SET(CURL_HFILES hugehelp.h setup.h config-win32.h config-mac.h [...]
SET(curl_SOURCES ${CURL_CFILES} ${CURLX_ONES} ${CURL_HFILES})

The problem is that add_executable() needs the full path to all source files outside the current dir. But config-win32.h is in ${CMAKE_SOURCE_DIR}/lib not in the current dir (src).

Solution:

Set the full path ${CMAKE_SOURCE_DIR}/lib/config-win32.h in Makefile.inc.cmake, e.g.:

SET(CURL_HFILES hugehelp.h setup.h ${CMAKE_SOURCE_DIR}/lib/config-win32.h config-mac.h [...]

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2012-03-16 14:46

Message:
This bug is reported in an older version and seems (or is possible) to have
been corrected in a more recent version.

If you can please upgrade and try it again with the latest version, it
would help a lot!

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2012-03-05 14:23

Message:
1. We run 'maketgz' to build tarballs/releases.

2. cmake is less good for us primarily because of two reasons: firstly
there's just nobody around who knows cmake and who contributes fixes to the
cmake build scripts while all seasoned hackers already are familiar with
autotools and have learned how to patch and work with them decently. Just
look at how we've had cmake support for almost three years now and we
really don't have contributions that fix the build and you can easily find
this amount of serious flaws. The second reason would be that cmake just
isn't present in most people's (legacy) *nix systems which makes it a
rather annoying extra dependency.

I don't see how opinions from someone maintaining a thing such as KDE which
is FAR less portable than curl is would change my view.

3. If I would kick one out, I'd kick out cmake because the autotools based
build we have is complete and up-to-date, while the cmake one is a long way
from that. And because I know autotools and not cmake. I accepted to add
the cmake build option (after much debate over the years) primarily because
lots of people claimed it would be as good as you say and I thought it was
worth giving it a shot. I've not been convinced about its greatness since
then. It hasn't done much harm either of course, since I honestly believe
hardly anyone uses this build option...

----------------------------------------------------------------------

Comment By: theret (theret)
Date: 2012-03-05 14:09

Message:
I would volunteer to help but I need more information from you to do so:

1. I am unable to figure out how exactly you create the daily tarball from
the git repository. Obviously it is something hidden and unmentioned in
GIT-INFO. Running the scripts that GIT-INFO suggests does not result in a
tree that is equal to the tarball.

2. I am surprised to hear that you still hold on to the aging autotools
since everybody is moving away from it. I thought you were transitioning to
cmake not away from it. I myself just ripped autotools out of a big project
because it is too complicated and difficult to maintain. And last but not
least because the Windows users complain that autotools is useless for
them. The effort I put in it paid off a lot already. Cmake does not depend
on shell scripts in the configuration and build process which makes it
actually portable. Since curl is developed on many platforms cmake would be
the ideal build system for it. In this case I pretty much agree with the
view of KDE developer Alexander Neundorf
(http://lwn.net/Articles/188693/).

3. I agree that maintaining two different build systems is tedious. But
since you already have two working an one them is cmake then given the list
of its supported platforms I don't understand why you wouldn't want to kick
out autotools instead.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2012-03-05 13:16

Message:
The info is already in GIT-INFO and yes, it is autotool-centric.

I don't have any solution for cmake, and I'm not able to produce any. If
you can help us with that then I'm interested.

To me, cmake support is a game we are doomed to lose and I am leaning
towards just completely ripping it out again.

----------------------------------------------------------------------

Comment By: theret (theret)
Date: 2012-03-04 15:16

Message:
1. OK, I looked at GIT-INFO but the scripts mentioned therein are not
relevant for cmake. They are autotools related. I don't have autotools
(e.g. windows) and hence want to build curl with cmake. So what do I have
to do exactly before I can do that? Which script does the "massaging"?

2. As a sidenote: people who use cmake for building are potentially unable
to run shell scripts to do the massaging. so ideally curl should take care
of creating necessary support files itself with cmake scripts.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2012-03-04 14:35

Message:
Yes, you need a script to "massage" it after a git checkout, as is detailed
in the GIT-INFO file.

There's also scripts run when the tarballs are made so we should make sure
what you need isn't made only then.

----------------------------------------------------------------------

Comment By: theret (theret)
Date: 2012-03-02 17:26

Message:
I can confirm it works with the daily tarball. Do you apply a certain
script to do the "massaging"? Is there a way for me to reproduce that?

----------------------------------------------------------------------

Comment By: Dan Fandrich (dfandrich)
Date: 2012-02-27 14:34

Message:
Have you tried one of the daily tarballs instead of the git repository? The
git repo needs some massaging of files to make it ready for building, and
IIRC some of the config files are copied during the massaging that happens.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3494982&group_id=976
Received on 2012-03-16