search

adah1972 / libunibreak

The libunibreak library
zlib License
173 stars 38 forks source link

Does not even build #3

Closed shvelo closed 10 years ago

shvelo commented 10 years ago

Missing files

tasn commented 10 years ago

Shit. :) I will have to take a look. Which files?

On 2 February 2014 19:19:25 CET, Nick Shvelidze notifications@github.com wrote:

Missing files

Reply to this email directly or view it on GitHub: https://github.com/adah1972/libunibreak/issues/3

shvelo commented 10 years ago 
configure.ac:11: error: required file './ltmain.sh' not found
configure.ac:5: error: required file 'config.h.in' not found
tasn commented 10 years ago

Sounds like an issue with your setup. Trying running the whole autoreconf and bla bla...

Tom.

On 2 February 2014 19:51:31 CET, Nick Shvelidze notifications@github.com wrote:

configure.ac:11: error: required file './ltmain.sh' not found
configure.ac:5: error: required file 'config.h.in' not found

Reply to this email directly or view it on GitHub: https://github.com/adah1972/libunibreak/issues/3#issuecomment-33908462

bakercp commented 10 years ago

If you are on a mac, you may need to install dependencies with brew or equivaleent and you will need to modify the ./bootstrap script to use glibtoolize rather than libtoolize. Also, for whatever reason I had to manually create the m4 directory or autoreconf would fail. Here is my step by step boostrap-equivalent commands for a OSX:

mkdir -p m4
aclocal
autoheader
autoconf
glibtoolize
automake --add-missing
autoreconf

Alternatively, it's pretty easy to just include the source files in your project without building the libs.

tasn commented 10 years ago

Ok, so it's a Mac thing. I'll take a look tomorrow.

Tom.

On 9 February 2014 01:50:21 GMT+00:00, Christopher Baker notifications@github.com wrote:

If you are on a mac, you may need to install dependencies with brew or another you will need to modify the ./bootstrap script to use glibtoolize rather than libtoolize. Also, for whatever reason I had to manually create the m4 directory or autoreconf would fail. Here is my step by step boostrap-equivalent commands for a OSX:

mkdir -p m4
aclocal
autoheader
autoconf
glibtoolize
automake --add-missing
autoreconf

Reply to this email directly or view it on GitHub: https://github.com/adah1972/libunibreak/issues/3#issuecomment-34562818

shvelo commented 10 years ago

Actually I'm building on Linux, but this might work

tasn commented 10 years ago

Fixed. Just did the same as what I usually put in my autogen.sh file. Indeed the thing was wrong.

Thanks for reporting, and sorry, but I neglected to give you credit for finding this. :(

Tom.

On 9 February 2014 14:59:32 GMT+00:00, Nick Shvelidze notifications@github.com wrote:

Actually I'm building on Linux, but this might work

Reply to this email directly or view it on GitHub: https://github.com/adah1972/libunibreak/issues/3#issuecomment-34575968

bakercp commented 10 years ago

Super! Fixed my issue. No worries on credit. Cheers, Christopher

adah1972 commented 10 years ago

I actually tested on Cygwin and Mac Lion (I symlinked glibtoolize to /usr/local/bin/libtoolize, though). It worked for me.

A few questions:

adah1972 commented 10 years ago

Hi shvelo,

Did you run ./bootstrap followed by ./configure from the git source, or did you just run ./configure from the downloaded tarball?

-Yongwei

tasn commented 10 years ago

You are right. Can remove configure. Touch are just from my template to create if don't exist. Libtoolize/glibtoolize: it's essential, I copied it from another project I work on where we do the same.

On 12 February 2014 05:31:41 GMT+00:00, Wu Yongwei notifications@github.com wrote:

I actually tested on Cygwin and Mac Lion (I symlinked glibtoolize to /usr/local/bin/libtoolize, though). It worked for me.

A few questions:

  • Are the two "touch" lines necessary?
  • Should "glibtoolize" be before "libtoolize"? I think the intention is to use the GNU libtoolize, and I am not sure whether there exists a non-GNU libtoolize. (I am not near a Mac now.).
  • I think the configure lines should be removed. The bootstrap script is intended to generate code enough for distributing the source. Configure is a separate step, and I normally do it in a separate directory.

Reply to this email directly or view it on GitHub: https://github.com/adah1972/libunibreak/issues/3#issuecomment-34840388

adah1972 commented 10 years ago

I have tested on both Linux and Mac. It seems creating the m4 directory manually is needed, if "-I m4" is used on the command line. Anyway, it is safe to create the directory, and it probably more portable. "--copy" is needed on my test Linux box for some reason, but it is not on Mac. autoreconf is still necessary on my Mac, so I will add it back.

I do not see the reason to touch non-existent files, and I will remove them, as well as the macro usage. I will also add credits in the Change Log :-).

tasn commented 10 years ago

Maybe you could delete the m4 dir and the -I if we don't plan on having m4. --copy is needed on linux to copy missing files, no idea about mac. I wonder why autoreconf would be needed, as it's for updating, not initial creation, and should be invoked automatically.

Yeah remove them and the m4, although we added them because we had issues in the past. Just fyi.

adah1972 commented 10 years ago

I added "autoreconf" last year, when I encountered (and still have) this problem:

libtool: Version mismatch error. This is libtool 2.4.2, but the libtool: definition of this LT_INIT comes from libtool 2.2.10. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 libtool: and run autoconf again.

I googled around and found the solution.

As to "--copy", it is actually only needed on file systems that do not support symlinking. I think it is optional is most cases. Anyway, there is no need to change it, nor is there need to change the m4 part now.

tasn commented 10 years ago

Oh right, now I remember. We added the --copy because of windows or maybe it was filesystems without symlinks, you are right.

autoreconf looks like a wrong solution to the problem. I wonder if the m4 dir and all of the change I've added actually work out nicely. autoreconf should be used by people who reconf. :) Maybe you have something wrong with your system? I.e an old libtool lingering around in PATH or something like that?

tasn commented 10 years ago

By the way, the reason why I added the configure there, is that I copied the (more commonly used?) autogen.sh script from the other project, and didn't adjust it to our "bootstrap". Maybe we should consider switching to that more common (at least in my circles) practice?

adah1972 commented 10 years ago

I tested, and it seems autoreconf is necessary. Google reveals it is not just a Mac problem. I think some autotools may have a different version from libtoolize, but I do not deal with the versions myself. I just use MacPorts. And at least some Linux people encountered this problem too, and autoreconf may help (at least it does no harm).

adah1972 commented 10 years ago

Is there an essential difference, apart from the naming?

I have just checked a few random projects on SourceForge, and found one that contains an autogen.sh (none contains a bootstrap, though I believe I chose "bootstrap" from an open-source project). However, in this project (FileZilla), autogen.sh does not do configure, either.

tasn commented 10 years ago

The include of configure. Odd that you can't find any. I'll try and take a look.

On 13 February 2014 06:09:09 GMT+00:00, Wu Yongwei notifications@github.com wrote:

Is there an essential difference, apart from the naming?

I have just checked a few random projects on SourceForge, and found one that contains an autogen.sh (none contains a bootstrap, though I believe I chose "bootstrap" from an open-source project). However, in this project (FileZilla), autogen.sh does not do configure, either.

Reply to this email directly or view it on GitHub: https://github.com/adah1972/libunibreak/issues/3#issuecomment-34951210

tasn commented 10 years ago

Just checked the projects I have checkout's of here: Enlightenment.org: autogen.sh Fontconfig: autogen.sh Freetype: autogen.sh without automatically running configure. Fribidi: bootstrap with configure Harfbuzz: autogen.sh Pango: autogen.sh

As you can see, a landslide win for autogen.sh that automatically run configure unless the NOCONFIGURE environment var is set. So essentially like what I added. I'd assume GTK+ is the same as pango, not sure though.

tasn commented 10 years ago

Oops, I also have cairo here. Cairo: autogen.sh

adah1972 commented 10 years ago

I can see that autogen.sh is more popular than bootstrap, but there is no pressing need to make the change. I do not want to change for change's sake, especially considering tarball downloaders do not need to use bootstrap or autogen.sh at all.

Whether it is autogen to bootstrap, I do not want it to do ./configure. I simply do not like it. I always bootstrap and configure in different directories.

Let us close this issue and do not bother others. If you still want to discuss on this, we can communicate in e-mail or discuss somewhere else.

tasn commented 10 years ago

No need to discuss it further. I agree with everything you said. However, let me just say I also do out of source builds, that's why there's the NOCONFIGURE in autogen.sh.

Tom.

On 15 February 2014 14:41:03 GMT+00:00, Wu Yongwei notifications@github.com wrote:

I can see that autogen.sh is more popular than bootstrap, but there is no pressing need to make the change. I do not want to change for change's sake, especially considering tarball downloaders do not need to use bootstrap or autogen.sh at all.

Whether it is autogen to bootstrap, I do not want it to do ./configure. I simply do not like it. I always bootstrap and configure in different directories.

Let us close this issue and do not bother others. If you still want to discuss on this, we can communicate in e-mail or discuss somewhere else.

Reply to this email directly or view it on GitHub: https://github.com/adah1972/libunibreak/issues/3#issuecomment-35157641