building a program with ghc

2024-03-18 Thread PICCA Frederic-Emmanuel
Hello,

I am trying to write rules in order to build a program with ghc

I end up with this, I think that I could improve all this a lot.

So I would like your advices in order to improve this

thanks for considering

Frederic

GHCLINK = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=link $(GHC) $(AM_CFLAGS) $(CFLAGS) \
$(AM_LDFLAGS) $(LDFLAGS) -o $@

.hsc.o:
# fake in order to let automake generate clean rules for _OBJECTS files
hsc2hs --cflag=$(AM_CFLAGS) -o $@ $<

.hs.o:
# fake in order to let automake generate clean rules for _OBJECTS files
ghc --make -i$(srcdir)/src -i$(builddir)/src -outputdir=$(builddir)/src 
-c -O -o $@ $<


hsc_sources=\
src/Hkl/C/Hkl.hsc \
src/Hkl/C/Binoculars.hsc

sources=\
src/Hkl.hs \
src/Hkl/Binoculars.hs \
src/Hkl/Binoculars/Command.hs \
src/Hkl/Binoculars/Common.hs \
src/Hkl/Binoculars/Config.hs \
...

CLEANFILES=\
src/Hkl/Binoculars.hi \
src/Hkl/Binoculars/Config.hi \
src/Hkl/Binoculars/Config.dyn_o \
src/Hkl/Binoculars/Config.dyn_hi \
src/Hkl/Binoculars/Config/Common.hi \
src/Hkl/Binoculars/Config/Sample.hi \
...

bin_PROGRAMS = binoculars-ng
binoculars_ng_SOURCES = $(hsc_sources) $(sources)
binoculars_ng_LDADD = \
$(top_builddir)/hkl/libhkl.la \
$(top_builddir)/binoculars/libhkl-binoculars.la
binoculars_ng_LINK=$(GHCLINK) \
-i$(srcdir)/src -i$(builddir)/src -outputdir=$(builddir)/src \
$(builddir)/src/Hkl/C/Hkl.hs \
$(builddir)/src/Hkl/C/Binoculars.hs \
$(srcdir)/app/Binoculars.hs


binoculars-ng$(EXEEXT): $(binoculars_ng_DEPENDENCIES) 
$(EXTRA_binoculars_ng_DEPENDENCIES)
@rm -f binoculars-ng$(EXEEXT)
mkdir -p $(builddir)/src/Hkl/C/
@rm -f src/Hkl/C/Hkl.hs
$(HSC2HS) --cflag=$(AM_CFLAGS) -o src/Hkl/C/Hkl.hs 
$(srcdir)/src/Hkl/C/Hkl.hsc
@rm -f src/Hkl/C/Binoculars.hs
$(HSC2HS) --cflag=$(AM_CFLAGS) -o src/Hkl/C/Binoculars.hs 
$(srcdir)/src/Hkl/C/Binoculars.hsc
$(AM_V_GEN)$(binoculars_ng_LINK) $(binoculars_ng_LDADD) $(LIBS)



Re: libtool relink problem

2011-07-08 Thread emmanuel

On Thu, 30 Jun 2011 14:38:49 +0200, Pippijn van Steenhoven wrote:

On Wed, Jun 29, 2011 at 05:14:19PM +0200, Emmanuel Engelhart wrote:



From: Pippijn van Steenhoven
Date: Mon, Jun 20, 2011 at 4:55 PM
Subject: Re: libtool relink problem
To: automake@gnu.org


On Sun, Jun 19, 2011 at 03:40:06PM +0530, Santhosh Thottingal 
wrote:

Hi,
I am facing a problem with libtool. While installing it complains  
a

relink  required and while doing so it tries to link against the
shared library instead of static library.
Well, the problem is better explained in this thread
http://sourceware.org/ml/automake/2004-07/msg00127.html with 
example

code.

I am facing exactly the same problem.

I saw a similar problem in this thread also
http://www.mail-archive.com/libtool@gnu.org/msg00782.html

Is there a solution available for this?


Thanks
Santhosh


Hi Santhosh,

I suggest writing your *_LTLIBRARIES with a comment in front, 
perhaps
with #>  to differ between disabled and enabled libraries. Then 
using

grep(1) to extract the names and the same tools to extract the
dependencies. You can then use tsort(1) to topologically sort the
libraries and write the actual ${dir}_LTLIBRARIES to an included 
.am
file. Semantically, this is what I do. In reality, I wrote a 
preprocessor
for automake that does this, but I don't suggest using it, as it's 
beta

and very much tailored to my needs.

Hi Pippijn

Thank you for taking time and trying to help us... because we really 
get

stucked.

I tried to understand your answer but I honestly think I'm not good
enough with automake to be able to understand and apply your
methodology. I also doubt that the other cases given by Santhosh are 
the

same as our, although the symptom is.

From my understanding the previously described issues occur if the
dependences are not compiled in the right order. I think this is not 
our
problem because at the moment the error occurs, I know the 
dependence is

already compiled.


The issue occurs if the dependencies are not _installed_ in the right
order.

So, I'm sure the file $(top_builddir)/src/ctpp2/src/libctpp2.la 
exists.


As you noted, the dependency has been compiled and linked, but for
installation, it has to be relinked:


libtool: relink: g++ -shared -nostdlib

   ^^

The above occurs in make install.


So my question is why automake replaces the path with libcttp2.la in
-lctpp2, replacing a static linking with a dynamic one?


It's related to rpath linking. The resulting binaries are relinked to
include $(libdir) as rpath, so that installed binaries can be called 
and

libraries loaded without listing $(libdir) in LD_LIBRARY_PATH or
ld.so.conf.

It looks like you are using a recursive make, in your project. Are 
you

sure that libcttp2.la exists in $(libdir)? As an experiment, try make
install in libctpp2's $(builddir) and then make install in
$(top_builddir).


So problem was fixed by using the "noinst" prefix for the ctpp2 code. 
If I correctly have understood the autotools behaviour it seems that if 
you don't use "noinst" prefix, the autotools install the libraries. In 
our case this does not make sense as the *.la files are only linked one 
time during the software compilation and not used afterwards (for 
example from thirds projects).


Thx you again Pippijn vor your help, without your answer I wouldn't 
have discover that the static lib were installed.


Regards
Emmanuel



libtool relink problem

2011-06-29 Thread Emmanuel Engelhart
 I'm sure the file $(top_builddir)/src/ctpp2/src/libctpp2.la exists.

So my question is why automake replaces the path with libcttp2.la in 
-lctpp2, replacing a static linking with a dynamic one?


Regards
Emmanuel



RE : call for help/crazy idea: nmake suppor t

2010-08-11 Thread PICCA Frédéric-Emmanuel
Hello

> I'm certainly quite eager to see this in Automake and Libtool.  I
> suspect this will hit the sweet spot for a lot of autotools users.

the problem I see is that a lot's of peoples relies on pkg-config
during the configuration phase.

How can we deal with this on windows platform ?



embeding a shared library into another one

2010-03-07 Thread PICCA Frédéric-Emmanuel
Hello

I am using the bullet project [1]

The author said that the best things to do is to statically link the libraries 
provided by their
projetc.

so I copy the bullet sources into my own project ans add a

configure.ac
AC_CONFIG_SUBDIRS(/path/to/bullet)

now I create my how library which use thie bullet libraries.

So I add for my library
AM_LDFLAGS = -version-info 0:0:0 \
$(HKL_LIBS) \
$(G3D_LIBS) \
./bullet/src/libbulletmath.la \
./bullet/src/libbulletcollision.la

lib_LTLIBRARIES = \
libhkl3d.la

libhkl3d_la_SOURCES = \
hkl3d.cpp

Now my problem is : I want to embed the code of bullet in my share library
that way A programm using my library just need to link agains my hkl3d library.
A sort of : link all .os object of bullet into my own library

How can I do this ?

thanks

Frederic

[1] http://bulletphysics.org/wordpress/