libsass version is missing when building to a new directory

[drewwells]

When configuring libsass from a clean directory, libsass_version always reports "[NA]". Even though, make install has the correct version in $(build_path)/include/sass_version.h.

So here's what I did...

cd src; autoreconf -fvi
cd build; ../src/configure --disable-shared --prefix=$(shell pwd) --disable-silent-rules --disable-dependency-tracking
cd build; make install

I guess it is still building the static library from src rather than from the files in build that are laid down by configure. Since configure lays down the files in the current directory rather than source directory, the modified sass_version.h is in build/. However, the archive file appears to have "[NA]" baked into it.

Here's my makefile: https://github.com/wellington/go-libsass/blob/master/Makefile#L20

[mgreter]

We don't actually release any archives. If you create one, you decouple the source files from git control and have to add a VERSION file. I have this automated with perl-libsass, since I also include the full sources with the distribution: http://cpansearch.perl.org/src/OCBNET/CSS-Sass-v3.2.2/libsass/VERSION. We really don't want to have the version baked into git either!!

[drewwells]

It is cool that it will read a VERSION file, good to know!

This is not for generating archives, it's for making custom configured versions of libsass. configure is designed to allow for this behavior. You could for instance do.

cd ../shared-libsass; ../libsass/src/configure --enabled-shared
cd ../static-libsass; ./libsass/src/configure --disabled-shared

This already works properly, but the versioning is missing. A build rule or changing the order of things happening would fix this though... This is the recommended way of working on implementation projects that want to maintain a pristine source. However, when you do either of these the sass_version.h file still gets modified in the source. It should instead modify the target location.

[mgreter]

We need that header at build time, since it will be baked into the library. Thinking about it, I see that we should not really install sass_version header, since it serves no purpose for implementors (you should never include it, always call libsass_version function of the library)!

The file is overwritten by the configure step, so I guess if you modify it after that step, it should be picked up. But I really have a hard time to follow your steps. Your makefile is incomplete and the version target is never called or used as a dependency!? So it's hard to tell what is going wrong, but it should certainly work, as I just tested locally!

[drewwells]

src refactor fixed this issue, It is now working.

mkdir -p $(NEWDIR);
cd $(LIBSASS_SRC); autoreconf -fvi
cd $(NEWDIR); $(LIBSASS_SRC)/configure

sass_version.h in NEWDIR has the correct version information.

[saper]

Isn't configure enough? autoreconf should not be necessary

[drewwells]

Apparently not? I get errors without autoreconf

git submodule update --init
# generate version header from configure script
cd libsass-src; /Library/Developer/CommandLineTools/usr/bin/make clean
rm -f lib/*.a lib/*.so lib/*.dll lib/*.la
rm -f   src/cencode.o src/ast.o src/base64vlq.o src/bind.o src/color_maps.o src/constants.o src/context.o src/cssize.o src/emitter.o src/environment.o src/error_handling.o src/eval.o src/expand.o src/extend.o src/file.o src/functions.o src/inspect.o src/json.o src/lexer.o src/listize.o src/memory_manager.o src/node.o src/output.o src/parser.o src/plugins.o src/position.o src/prelexer.o src/remove_placeholders.o src/sass.o src/sass_util.o src/sass_values.o src/sass_context.o src/sass_functions.o src/sass_interface.o src/sass2scss.o src/source_map.o src/to_c.o src/to_string.o src/to_value.o src/units.o src/utf8_string.o src/values.o src/util.o
mkdir -p libsass-tmp
# configure libsass
cd libsass-tmp; ../libsass-src/configure --disable-shared \
            --prefix=/Users/drew/src/github.com/wellington/go-libsass --disable-silent-rules \
            --disable-dependency-tracking
/bin/sh: ../libsass-src/configure: No such file or directory
make: *** [libsass-tmp] Error 127

I'm super happy to see a pristine libsass-src after this runs now though 👯 👯 💃

[saper]

Apparently not? I get errors without autoreconf

cd libsass-tmp; ../libsass-src/configure --disable-shared \
          --prefix=/Users/drew/src/github.com/wellington/go-libsass --disable-silent-rules \
          --disable-dependency-tracking
/bin/sh: ../libsass-src/configure: No such file or directory
make: *** [libsass-tmp] Error 127

I am sorry, I misunderstood the issue! Of course we don't ship ./configure
script in the git repository. What I meant is that ./configure should be enough
to create the version information, but of course you need to have
that script first :)

Sorry for noise!

[drewwells]

No problem I'm still not great with auto tools but I am reading through the
book on it! :)
On Tue, Jul 21, 2015 at 11:30 AM Marcin Cieślak notifications@github.com
wrote:

Apparently not? I get errors without autoreconf

cd libsass-tmp; ../libsass-src/configure --disable-shared \
--prefix=/Users/drew/src/github.com/wellington/go-libsass
--disable-silent-rules \
--disable-dependency-tracking
/bin/sh: ../libsass-src/configure: No such file or directory
make: *** [libsass-tmp] Error 127

I am sorry, I misunderstood the issue! Of course we don't ship ./configure
script in the git repository. What I meant is that ./configure should be
enough
to create the version information, but of course you need to have
that script first :)

Sorry for noise!

—
Reply to this email directly or view it on GitHub
#1223 (comment).

[saper]

No problem I'm still not great with auto tools but I am reading through the book on it! :)

This is highly recommended: http://www.dwheeler.com/autotools/

[drewwells]

Oh nice, bookmarked

On Tue, Jul 21, 2015 at 1:18 PM Marcin Cieślak notifications@github.com
wrote:

No problem I'm still not great with auto tools but I am reading through
the
book on it! :)

This is highly recommended: http://www.dwheeler.com/autotools/

—
Reply to this email directly or view it on GitHub
#1223 (comment).