Hi,
thanks for your reply.
On the other hand, CMake would probably be less than helpful for the
SML
parts, which comprise a significant portion of the codebase as far as I can
see, you'd have to work with add_custom_command which isn't that wonderful.
(For common languages like C/C++ and a few others, CMake does a lot of stuff
for you, but less common ones aren't really supported and you end up having
to write CMake commands equivalent to makefile rules.)
So each tool has its advantages and drawbacks.
Signed. Of course CMake was an alternative but since I already had
Makfiles as a base to start from...
Maybe I'll test out CMake too.
Normally testsuites can use the just-built compiler directly from the
source
tree. Look at existing projects and how they handle this. As you're using
autotools, I guess GCC would be a good place to look.
Ah, yeah. Thanks for the hint.
Sure, I don't see why not. You just need to be careful when
building (you
need to build the object files to different places so they don't conflict).
That's one nice feature of automake. In fact the old buildsystem used
suffix rules (*.p.o *.g.o) to build different object files. Automake
handles this automagically.
Hmmm, that's a bit at the limit, 3 letters are a bit short for a
unique
name. :-( But there's no librml.so in Fedora yet as far as repoquery tells
me, so at least there's no current conflict. Let's see what others think.
If that's the upstream project name (used in things like
tarballs), it's
fine. (But is the MixedCase really necessary? :-( Usually things like
tarball and package names are all lowercase, but sometimes MixedCase is used
by upstream and the Fedora packages usually match that. Probably something
to discuss with upstream.)
I convinced upstream that a new name like rml-mm (for "rml with
metamodelica support" would be a good thing, so both problems will
probably be solved soon.
> The package builds a compiler driver, essentially a shell
script, by
> copying some configuration variables into a shell template (mainly how
> to invoke cc). Would this be fine as a /usr/bin script?
Yes, but beware of multilib conflicts: if that script is in the same package
as some libraries, that package will end up multilibbed due to the libraries
and if the script is not identical for 32-bit and 64-bit, there will be a
conflict between the 2 multilibbed packages. (Splitting out the libraries
into a -libs package is a way to work around that.)
Since the compiler seems to run without the libs two (sub-)packages
might indeed be a good idea.