piqic-erlang plugin

[Motiejus Jakštys]

Hi,

I am making a rebar plugin for piqi to reduce number of LOC of Makefiles
in our projects. It works as follows:

{plugins, [piqi_plugin]}.
{piqi_plugin, [
{piqic_erlang, "priv/labels-defs.piqi", ["-I", "priv"]
}
]
}.

This works now. However, it fails when we start including headers
elsewhere. Consider this:

{piqi_plugin, [
{piqic_erlang, "priv/labels-defs.piqi", [
"-I", "priv",
"-I", {deps_dir, "gidless_core/priv/gidless.piqi"}
]
}
]
}.

During plugin invocation I replace {deps_dir, ...} with something more
appropriate. OK. However, the labels_defs_piqi.erl has one flaw:

-include("gidless_piqi.hrl").

And rebar can't find it! I want it to be:

-include_lib("gidless/include/gidless_piqi.hrl").

I could handle this in the plugin by just running re:replace on the
resulting files. However, seems like it is pretty difficult to figure
out the filenames of the artefacts!

The plugin itself is 30 LOC, but the speed how LOC for workarounds is
increasing brings me fear (extra 50 LOC for only deps_dir hack). I would
rather avoid this filename deduction in the plugin.

If you think this approach to change the include paths is valid, how
would you recommend to figure out the filename of the artefacts, so I
can do the nasty editing? First thing that comes to my mind is just
return the filenames from piqic_erlang. However, I am not sure if you
will like this.

What is more, for `clean` phase we also need to know the filenames of
the artefacts. So it would be very nice to have an easy way to convert
from piqi filename to list of .erl/.hrl filenames without a lot of
magic.

Any other ideas?

Once the plugin is working and tested (in Spil), we will share it.

Motiejus

[Anton Lavrik]

On Thu, May 16, 2013 at 11:19 PM, Motiejus Jakštys <desir...@gmail.com> wrote:

Hi,

I am making a rebar plugin for piqi to reduce number of LOC of Makefiles
in our projects. It works as follows:

{plugins, [piqi_plugin]}.
{piqi_plugin, [
        {piqic_erlang, "priv/labels-defs.piqi", ["-I", "priv"]
        }
    ]
}.

This works now. However, it fails when we start including headers
elsewhere. Consider this:

{piqi_plugin, [
        {piqic_erlang, "priv/labels-defs.piqi", [
                "-I", "priv",
                "-I", {deps_dir, "gidless_core/priv/gidless.piqi"}
            ]
        }
    ]
}.

During plugin invocation I replace {deps_dir, ...} with something more
appropriate. OK. However, the labels_defs_piqi.erl has one flaw:

    -include("gidless_piqi.hrl").

And rebar can't find it! I want it to be:

    -include_lib("gidless/include/gidless_piqi.hrl").

I could handle this in the plugin by just running re:replace on the
resulting files. However, seems like it is pretty difficult to figure
out the filenames of the artefacts!

But are you sure you absolutely have to solve this problem? I've been successfully using .piqi symlinks and -I flags for piqic-erlang and erlc to work around it. I understand that -include_lib(...) in your example looks nicer, but in the end, I'm not sure if it makes any difference from practical standpoint.

Makefiles can be pretty reasonable and moreover they can definitely be generalized so that you can just have some common set of rules included in your Makefile.piqi. For example, in the following Makefile everything except for perhaps 3 lines is generic: https://github.com/alavrik/piqi-rpc/blob/master/examples/addressbook/src/Makefile.piqi

Makefiles can get ugly and they don't work in all cases (on all platforms), but hey, they are flexible and completely transparent as opposed to custom rebar plugins. For instance, creating a symlink or adding a command-line parameter that depends on $REBAR_DEPS_DIR can't be simpler in Makefiles.

I think rebar is nice. It does the right thing with minimal input from a user in 90% of cases. However, piqi is clearly an external tool. It has many features and it will be evolving. I had been thinking about what would cover 90% of Piqi-erlang use cases but it was hard (and still is) to come up with definite answers. In the end, given make's versatility, transparency and general convenience, I didn't see much need for a piqic-erlang rebar plugin.

One thing I would probably consider is calling Makefile.piqi without having to explicitly specify "compile" and "clean" hooks. But even this doesn't sound transparent and user-friendly to me.

Just my 2 cents...

Anton

[Motiejus Jakštys]

Hi,

we have some similar cases. erlang_protobuffs[1] and erlydtl[2]. These
also generate artefacts and are external tools. Both have executables
you can run to compile artefacts (in bin/ of both projects); however,
rebar automagic is preferred. If you put files to the proper
directories, rebar will see them and compile them automatically[3][4].

*Everyone* uses rebar automagic to generate these files because it is
convenient.

Given that, I am not saying we have to get rid of Makefiles. Like in
these two projects, I am trying to *complement* them.

While you may dislike piqic definitions in rebar.config (we certainly do
like them, but I understand it is a matter of taste), having a more
flexible compiler would benefit us all: we can easily integrate it to
Make, cmake, rebar or *whatever*. Currently, piqic-erlang is not
flexible enough to make it a rebar plugin. All I am asking is a few
helper functions which will make making a new compiler abstraction
easier. Why not give a choice for the user how she wants to compile the
artefacts?

Since we are not basho, we cannot include rebar_piqic_compiler to rebar
(haha, that would be fun), however, we can write a plugin*.

> One thing I would probably consider is calling Makefile.piqi without having
> to explicitly specify "compile" and "clean" hooks. But even this doesn't
> sound transparent and user-friendly to me.

We have been using piqi for more than a year now for maybe one or two
projects, and know where it hurts makewise (pun intended).

Given that, I am not masturbating around rebar plugins because I like
them (frankly, support for plugins in rebar is immature and sucks). But
we want to reduce the pain of builds I am talking about. Obvious way is
to abstract Makefiles. This is what I am doing.

rebar is the reason why we have rebar. Why aren't we doing this?
top-level Makefile::

SRCS := $(wildcard src/*.erl)
EBINS := $(imagine_the_mess)
ALL_DEPS := deps/cowboy deps/erlualib
compile: $(ALL_DEPS) $(BEAMS)

deps:
mkdir -p deps
deps/cowboy: deps
$(CLONE_DEP) git://github.com/extend/cowboy.git
$(CHECKOUT) 0.6.0
deps/erlualib: deps
do_you_want_me_do_do_this?
ebin/%.beam: src/%.erl
do_you_really_want_me_to_do_this?

Amazingly, people did that until rebar was invented. It just abstracts
all this stuff for 98% of the cases. Where rebar is insufficient, you
are free to use Makefile.

So yes, this plugin will solve a lot of our problems (and I am pretty
sure other user's problems who will use piqi for more than 10 projects).
We are ready to make and share the plugin, however, the compiler has to
be a bit more friendly for plugin writers like me. :-)

I am ready to modify the compiler to be more friendly to the plugin.
However, want to do it in a way most acceptable for upstream maintainer,
You.

[1]: https://github.com/basho/erlang_protobuffs
[2]: https://github.com/evanmiller/erlydtl
[3]:
https://github.com/rebar/rebar/blob/2.1.0-pre/src/rebar_protobuffs_compiler.erl#L39
[4]: https://github.com/rebar/rebar/blob/2.1.0-pre/src/rebar_erlydtl_compiler.erl#L29
[*]: technically not yet, because of a bug in rebar plugin handling that
I am just about to submit a fix for.

[Anton Lavrik]

Hi Motiejus,

Don't get me wrong -- I'm totally fine with your decision to work on rebar plugin for piqi. And I will try to help if you need any changes in the piqi compiler.

Overall, I think that rebar is a useful and generally nice tool. The fact protobuffs and erlydtl compilers are built-in means they can't be extended easily and also they are turned on by default which is not always the desired behavior. This is likely  an early design mistake that nobody really cares about fixing. More importantly, with rebar plugins like that you are inevitably introducing another notation and a layer for modifying the behavior of a build tool, in this case, piqic-erlang. Such layer needs to be documented, kept in sync with up-stream features and so on. Makefiles don't have that problem. But again, I can see the reasons why you want to have the rebar plugin.

Anyway... The approach you suggested in your first email won't work out of the box, because although piqic-erlang knows the names of .hrl and .erl artifacts generated for .piqi dependencies, it doesn't really know the directory in which these files where generated. It only knows directories of the source .piqi files it loads. The output directory is totally up to you. By default it is CWD and you can modify it using -O command-line option.

Let's see what how the compiler could help. For example, piqic-erlang could generate a list of {source directory, erlang module name} pairs and you could derive full output paths and include_lib paths of the artifacts from that. Another way is to implement the transformation you described by using a user-defined callback module called by piqic-erlang.

Which approach do you like better? Can you think of better ways?

Anton

--
You received this message because you are subscribed to the Google Groups "piqi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to piqi+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Motiejus Jakštys]

On Wed, May 22, 2013 at 01:29:13AM -0500, Anton Lavrik wrote:
> Hi Motiejus,
>
> Don't get me wrong -- I'm totally fine with your decision to work on rebar
> plugin for piqi. And I will try to help if you need any changes in the piqi
> compiler.

Thank you, this is great.

> Overall, I think that rebar is a useful and generally nice tool. The fact
> protobuffs and erlydtl compilers are built-in means they can't be extended
> easily and also they are turned on by default which is not always the
> desired behavior. This is likely an early design mistake that nobody
> really cares about fixing.

Sure. Normally these should be in the plugin. However, it was not
cleanly possible until[1] to do it using plugin, so they did a built-in.

> More importantly, with rebar plugins like that you are inevitably
> introducing another notation and a layer for modifying the behavior of
> a build tool, in this case, piqic-erlang. Such layer needs to be
> documented, kept in sync with up-stream features and so on. Makefiles
> don't have that problem. But again, I can see the reasons why you want
> to have the rebar plugin.

I do not see the difference from Makefile here. Both hold the same
requirements. Keeping the external interfaces documented and stable-ish
is the same as keeping the command-line arguments stable-ish.

> Anyway... The approach you suggested in your first email won't work
> out of the box, because although piqic-erlang knows the names of .hrl
> and .erl artifacts generated for .piqi dependencies, it doesn't really
> know the directory in which these files where generated. It only knows
> directories of the source .piqi files it loads. The output directory
> is totally up to you. By default it is CWD and you can modify it using
> -O command-line option.

I do not understand the paragraph above. First, you probably meant `-C`
for output directory?

piqi-erlang$ ERL_LIBS=.. ./piqic-erlang/piqic-erlang --help
Usage: ./piqic-erlang/piqic-erlang [options] <.piqi file>
Options:
...
-C <output directory> specify output directory
...

I uploaded the WIP plugin to github[2]. Essentially it invokes
piqic_erlang:piqic_erlang/2, just like piqic-erlang/src/piqic_erlang.erl
does. Now the plugin is a silly Makefile replacement, and I want to keep
it that way. Ideally it should not require anything from the compiler,
only what is possible to be sent (and received) via command line. That
will make the plugin really well decoupled from piqic-erlang internals.

Since the plugin specifies the output directory, I do not see a problem
here.

> Let's see what how the compiler could help. For example, piqic-erlang
> could generate a list of {source directory, erlang module name} pairs
> and you could derive full output paths and include_lib paths of the
> artifacts from that.

Please elaborate. What would be source directory and erlang module name?

I was thinking about something like this. If piqic-erlang would return a
list of tuples. In pseudo-spec:

-spec piqic_erlang(..., ...) -> {ok, [T]} | {error, list()} where
T = {"priv/defn.piqi", ["defn_piqi.erl"], ["defn_piqi.hrl"]}

Where first key is piqi input file, and second and third elements are
filenames generated from that piqi input file without the directory name
(plugin will know the output directory: it's either cwd(), or "-C").

That way plugin will be able to do any kind of nasty hacks to make the
dependencies right. Most importantly, in whatever language.

> Another way is to implement the transformation
> you described by using a user-defined callback module called by
> piqic-erlang.

Two things against this:
1. if someone will want to make an Ant plugin, she will not have this
functionality unless she makes an Erlang wrapper which calls Ant.
Ugly.
2. I do not have a clear idea what the callback could do.

> Which approach do you like better? Can you think of better ways?

First one. To make it compatible with CMake/Ant/Whatever plugins, we
have to expose the above from piqic-erlang executable as well. For
example, if "-v" is passed, then piqic-erlang executable will output
these tuples to standard-output (prefixed probably, so it can be easily
distinguished from other verbose messages), so other plugin writers can
parse it and use it just like my plugin could.

Also, piqic_erlang:piqic_erlang now will have to return

{ok, [T]} | {error, Msg}

instead of

'ok' | {error, Msg}

for the reasons mentioned above.

I am CCing Ignas, because he often thinks out of the box and might
propose something even cleaner; what is more, he will be one of the
first plugin users.

Hope you are enjoying your holiday!

Motiejus

[1]:
https://github.com/rebar/rebar/commit/252b31f2a4b95670ef75a6a712788af977e869e9
[2]: https://github.com/Motiejus/piqi-rebar-plugin

[Motiejus Jakštys]

On Wed, May 22, 2013 at 10:32:32PM +0300, Motiejus Jakštys wrote:
> On Wed, May 22, 2013 at 01:29:13AM -0500, Anton Lavrik wrote:
> > Hi Motiejus,
> >

> -spec piqic_erlang(..., ...) -> {ok, [T]} | {error, list()} where
> T = {"priv/defn.piqi", ["defn_piqi.erl"], ["defn_piqi.hrl"]}
>

Correction. It should be more something more like this:

T = {"priv/defn.piqi", [
{erl, ["defn_piqi.erl", "defn_piqi_impl.erl"]},
{hrl, ["defn_piqi.hrl"]}
]}.

To make it extensible should there will be more output forms from
piqic-erlang (say xsd :-).

> > Which approach do you like better? Can you think of better ways?
>
> First one. To make it compatible with CMake/Ant/Whatever plugins, we
> have to expose the above from piqic-erlang executable as well. For
> example, if "-v" is passed, then piqic-erlang executable will output

I meant one of "--debug" or "--trace" flags. Or a separate flag
especially for this.

Motiejus

[Motiejus Jakštys]

On Wed, May 22, 2013 at 10:32:32PM +0300, Motiejus Jakštys wrote:

> On Wed, May 22, 2013 at 01:29:13AM -0500, Anton Lavrik wrote:

<snip>

> To make it compatible with CMake/Ant/Whatever plugins, we
> have to expose the above from piqic-erlang executable as well. For
> example, if "-v" is passed, then piqic-erlang executable will output
> these tuples to standard-output (prefixed probably, so it can be easily
> distinguished from other verbose messages), so other plugin writers can
> parse it and use it just like my plugin could.
>

We also need this information before the compilation for `clean` target.
How slow and bad would it be?

Maybe something like "--simulate" flag, which does not create any
artefacts, but only returns that {ok, [T]}, which plugin could use for
cleaning stuff.

Motiejus

[Ignas Vyšniauskas]

Hi Motiejau, Anton,

Without getting too much into the small technicalities of the current
situation, the thing that needs change is very simple:

Support a way to specify the `-include/-include_lib` declarations in the
generated .hrl/.erl files in different ways.

There are at most 3 different cases:
1) the current one, filename only: `-include("piqi_artefact.hrl")`.
2) the OTP standard for libraries from other applications:
`-include("application_name/include/piqi_artefact.hrl")
3) the super-custom: `-include("sone_random_path/piqi_artefact.hrl")`

Now, it's always best to be super explicit and also to *not* allow too
many customisations. So IMHO custom-callbacks are a horrible idea.

Instead, wouldn't it be possible to pass something like
`--header-include-prefix="path"` (default: "") and
`--header-include-type=plain/lib` (default: plain) in the appropriate
place and later on pass the generated paths along the chain compilation
chain?

Or, if you want to keep it even more limited and simple, just add one
flag: `--header-application="application_name"` (default: not set) and
in case this is set generate things as in case 2. In case not set, do as
in case 1. This however prevents you from doing case 3, but maybe that's
good thing.

In any way, it's important that these things:
* are only specified once
* the right `-include{,_lib}` declarations+paths are only generated in
one place in the build chain and later explicitly passed, *NOT*
magically determined-via-passed-on-flags-or-anything at later stages.

My two cents.

--
Ignas

[Anton Lavrik]

Motiejus, Ignas,

How about this:

We could add --include-lib <application-name>/<path> command-line option to piqic-erlang. It is similar to -I in a sense that it specifies where to search for .piqi modules but instead of directory path the first component will refer to an Erlang application directory -- the same notation we use in Erlang's -include_lib() form. If a dependency is found in a directory specified by --include-lib ... then piqic-erlang will generate -include_lib(...) instead of plain -include().

In addition, we could implement "piqic-erlang -M" that would be similar to "gcc -M". It will print the .piqi dependency and the artifacts in a simple and easy to parse Makefile notation (one rule per line). For example:

    defn_piqi.erl defn_piqi.hrl: priv/defn.piqi

These interfaces are simple and the implementation can be relatively straightforward. Unless I'm missing something, it looks like this should cover the main use cases. What do you think?

Anton

[Motiejus Jakštys]

On Fri, May 24, 2013 at 10:50 AM, Anton Lavrik <ala...@piqi.org> wrote:
> Motiejus, Ignas,
>
> How about this:
>
> We could add --include-lib <application-name>/<path> command-line option to
> piqic-erlang. It is similar to -I in a sense that it specifies where to
> search for .piqi modules but instead of directory path the first component
> will refer to an Erlang application directory -- the same notation we use in
> Erlang's -include_lib() form. If a dependency is found in a directory
> specified by --include-lib ... then piqic-erlang will generate
> -include_lib(...) instead of plain -include().
>
> In addition, we could implement "piqic-erlang -M" that would be similar to
> "gcc -M". It will print the .piqi dependency and the artifacts in a simple
> and easy to parse Makefile notation (one rule per line). For example:
>
> defn_piqi.erl defn_piqi.hrl: priv/defn.piqi
>
> These interfaces are simple and the implementation can be relatively
> straightforward. Unless I'm missing something, it looks like this should
> cover the main use cases. What do you think?

Just double-checking. Would -M give the ability to read information by
invoking piqic-erlang directly without parsing its output? I.e.
piqic_erlang:piqic_erlang(piqic_erlang, ["-M"]) would return {ok,
StringLikeAbove} or {ok, [{"priv/defn.piqi", ["defn_piqi.erl",
"defn_piqi.hrl"]}]} ?

Otherwise I agree with everything.

--
Motiejus Jakštys

[Anton Lavrik]

Great! Yes, we can modify piqic_erlang:piqic_erlang/2 to return the tuples. And piqic_erlang:main/1 can format them and print line by line to stdout.

Anton

[Motiejus Jakštys]

On 2013.05.26 00:00, Anton Lavrik wrote:
> > In addition, we could implement "piqic-erlang -M" that would be
> similar to
> > "gcc -M". It will print the .piqi dependency and the artifacts in
> a simple
> > and easy to parse Makefile notation (one rule per line). For example:
> >
> > defn_piqi.erl defn_piqi.hrl: priv/defn.piqi
> >
> > These interfaces are simple and the implementation can be relatively
> > straightforward. Unless I'm missing something, it looks like this
> should
> > cover the main use cases. What do you think?
>
> Just double-checking. Would -M give the ability to read information by
> invoking piqic-erlang directly without parsing its output? I.e.
> piqic_erlang:piqic_erlang(piqic_erlang, ["-M"]) would return {ok,
> StringLikeAbove} or {ok, [{"priv/defn.piqi", ["defn_piqi.erl",
> "defn_piqi.hrl"]}]} ?
>
>
> Great! Yes, we can modify piqic_erlang:piqic_erlang/2 to return the
> tuples. And piqic_erlang:main/1 can format them and print line by line
> to stdout.

Hi Anton,

how is your schedule these days? Do you find some time to work on piqi?

We are now revamping our Makefiles in the build systems, and are
especially interested with this feature.

Greetings from Europe,
Motiejus

[Anton Lavrik]

Hi Motiejus,

I'm pretty busy now but I'll try to find some time this weekend. I need to think a little bit more about it... It shouldn't be very hard to add.

Cheers,

Anton

[Anton Lavrik]

Hi Motiejus,

Just pushed the change to piqi-erlang deps branch. Let me know what you think: https://github.com/alavrik/piqi-erlang/commit/2ce2c50fc47730b4a56b7da00738419d0d066ae0

Note that this feature relies on another small change I've made in piqi. You can find the latest version in master.

Also, I haven't done correspondent changes in piqi-rpc. They are trivial -- just wanted to make sure we got everything right in piqi-erlang first.

Anton

[Motiejus Jakštys]

On 2013.09.11 11:17, Anton Lavrik wrote:
> Hi Motiejus,
>
> Just pushed the change to piqi-erlang deps branch. Let me know what you
> think:
> https://github.com/alavrik/piqi-erlang/commit/2ce2c50fc47730b4a56b7da00738419d0d066ae0
>
> Note that this feature relies on another small change I've made in piqi.
> You can find the latest version in master.
>
> Also, I haven't done correspondent changes in piqi-rpc. They are trivial
> -- just wanted to make sure we got everything right in piqi-erlang first.

I read the documentation and skimmed through code, and from that it
looks exactly like what we need. Thanks!

However, at this time I will not have a chance to test it in the near
future; I will keep you posted when I sit down to the build system again.

Like I said before, my long-term plan is to create a rebar plugin to
completely abstract compilation of the piqi artefacts so Makefile are
not needed. Thanks for helping me with that!

Motiejus

[Anton Lavrik]

You are welcome! Let me know whenever you are ready to integrate with it. I'll keep this change in the deps branch until then.

[ddo...@gmail.com]

Hi there, I apologize for resurrecting this thread, but I have simmilar need in `include_lib' feature:

I have project with following structure:
erlang project proj_a, and two erlang libraries lib_b and lib_c, autogenerated from piqi definitions.

proj_a depends on lib_b.
lib_b depends on lib_c (some of the lib_b piqi files do includes of lib_c piqi files)

but generated *hrl* files from *lib_b* library looks like:

lib_b_file.hrl:
-include("lib_c_file.hrl").

On *lib_b* compilation phase everything is ok (although I must mangle rebar.config with erl_opts to
include lib_c).

Problem is on top proj_a compilation, it does include some hrls from proj_b, which does include from proj_c!
So I have to put same magic in proj_a rebar.config in order to compile lib_b, although there is no direct dependency
on lib_c from proj_a.

if all hrls in lib_b had had `-include_lib("lib_c/include/lib_c_file.hrl") that would resolve the problem.

[Anton Lavrik]

It looks like --include-lib option we discussed earlier in this thread should help. Just pushed support for it to master: https://github.com/alavrik/piqi-erlang/commit/6788f1360a80998e425106306fd2399917732e2b

Let me know if you run into any problems (didn't have time to retest in master).

Anton

--

You received this message because you are subscribed to the Google Groups "piqi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to piqi+uns...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Daniil Churikov]

Hi Anton, recently I have a time to more or less describe the problem, please take a look at this repo when you have time:
https://github.com/ddosia/my_piqi_app

I did try this new option `--include-dir', seems it is highly depends on where piqi files are located. In my case all generated files are moved to appropriate
places (hrls under `include/' dir, erls under `src/' dir). That was done in order to avoid this mess with erl_opts.

[Anton Lavrik]

On Mon, Sep 29, 2014 at 11:06 PM, Daniil Churikov <ddo...@gmail.com> wrote:

Hi Anton, recently I have a time to more or less describe the problem, please take a look at this repo when you have time:
https://github.com/ddosia/my_piqi_app

I did try this new option `--include-dir', seems it is highly depends on where piqi files are located. In my case all generated files are moved to appropriate
places (hrls under `include/' dir, erls under `src/' dir). That was done in order to avoid this mess with erl_opts.

Hi Daniil,

I was able to get it working. See the patch below.

Overall, it looks like a reasonable solution to me. You can improve it further by using symlinks instead of copying. Or, turn it around and generate files in piqi/ and then symlink them to src/ and include/

Anton

diff --git a/deps/lib1/Makefile b/deps/lib1/Makefile

index 392eeae..2c1bc3a 100644

--- a/deps/lib1/Makefile

+++ b/deps/lib1/Makefile

@@ -16,7 +16,8 @@ all: $(ERL_INCLUDE_DIR) $(ERL_FILES)

 

 $(ERL_FILES): $(ERL_SRC_DIR)/%_piqi.erl: $(PIQI_DIR)/%.piqi

  $(PIQIC) -C $(ERL_SRC_DIR) $< 

- mv $(ERL_SRC_DIR)/$*_piqi.hrl $(ERL_INCLUDE_DIR)

+ cp $(ERL_SRC_DIR)/$*_piqi.hrl $(PIQI_DIR)

+ cp $(ERL_SRC_DIR)/$*_piqi.hrl $(ERL_INCLUDE_DIR)

 

 $(ERL_INCLUDE_DIR):

  mkdir $@

diff --git a/deps/lib1/rebar.config b/deps/lib1/rebar.config

index ccccdfb..ea7ecd1 100644

--- a/deps/lib1/rebar.config

+++ b/deps/lib1/rebar.config

@@ -1,5 +1,5 @@

 {deps, [

-    {piqi, "", {git, "g...@github.com:alavrik/piqi-erlang.git", {tag, "v0.7.1"}}}

+    {piqi, "", {git, "git://github.com/alavrik/piqi-erlang.git", {branch, "master"}}}

 ]}.

 

 {pre_hooks, [

diff --git a/deps/lib2/Makefile b/deps/lib2/Makefile

index 8f7a779..33613ff 100644

--- a/deps/lib2/Makefile

+++ b/deps/lib2/Makefile

@@ -15,8 +15,9 @@ HRL_FILES = $(patsubst $(PIQI_DIR)/%.piqi, $(ERL_INCLUDE_DIR)/%_piqi.hrl, $(PIQI

 all: $(ERL_INCLUDE_DIR) $(ERL_FILES)

 

 $(ERL_FILES): $(ERL_SRC_DIR)/%_piqi.erl: $(PIQI_DIR)/%.piqi

- $(PIQIC) -I $(REBAR_DEPS_DIR)/lib1/piqi -C $(ERL_SRC_DIR) $< 

- mv $(ERL_SRC_DIR)/$*_piqi.hrl $(ERL_INCLUDE_DIR)

+ $(PIQIC) --include-lib lib1/piqi -C $(ERL_SRC_DIR) $< 

+ cp $(ERL_SRC_DIR)/$*_piqi.hrl $(ERL_INCLUDE_DIR)

+ cp $(ERL_SRC_DIR)/$*_piqi.hrl $(PIQI_DIR)

 

 $(ERL_INCLUDE_DIR):

  mkdir $@

diff --git a/deps/lib2/rebar.config b/deps/lib2/rebar.config

index c59144f..a731b2a 100644

--- a/deps/lib2/rebar.config

+++ b/deps/lib2/rebar.config

@@ -1,5 +1,5 @@

 {deps, [

-    {piqi, "", {git, "g...@github.com:alavrik/piqi-erlang.git", {tag, "v0.7.1"}}},

+    {piqi, "", {git, "g...@github.com:alavrik/piqi-erlang.git", {branch, "master"}}},

     lib1

 ]}.

 

[Daniil Churikov]

Thanks for your help, probably I will do like you did in the patch.
Just in the sake of curiosity, why "--include-lib" flag works like that, I mean it looks like
place where piqi files are located and piqic output files are located is different thing.
In my mind "--include-lib prefix_path" should produce something like "-include_lib(PrefixPath ++ "/" ++ Filename ++ ".hrl").

[Anton Lavrik]

On Wed, Oct 1, 2014 at 6:41 AM, Daniil Churikov <ddo...@gmail.com> wrote:

Thanks for your help, probably I will do like you did in the patch.
Just in the sake of curiosity, why "--include-lib" flag works like that, I mean it looks like
place where piqi files are located and piqic output files are located is different thing.
In my mind "--include-lib prefix_path" should produce something like "-include_lib(PrefixPath ++ "/" ++ Filename ++ ".hrl").

--include-lib ... implies -I ... which is used to locate .piqi dependencies of the module being compiled: https://github.com/alavrik/piqi-erlang/blob/master/src/piqic_erlang.erl#L162

piqic-erlang can't work without locating the dependencies. In other words, this is the primary function of this option. Location of the build artifacts is secondary and assumed to be relative to the .piqi source. I think this is the only reasonable default here.

In theory, we could add another option for specifying relative prefix of the generated .hrl files which will override the default (e.g. --hrl-path-prefix include), but I am not sure it would add a lot of value for somebody who is already using makefiles to drive piqic-erlang.

Maybe it is my personal thing, but I like makefiles and I like when things are explicit. I am also not obsessed over .hrl file location and I usually keep .piqi files under src/ for to keep things simple. That said, I'd be open to adding more options if somebody needs it for some kind of automated piqi build plugin that would make stricter assumptions, like .piqi files being located under piqi/ and all .hrl under include/

Anton

[Daniil Churikov]

Thanks, Anton. I think current solution is quite acceptable for me, I'd rather no complicate piqic-erlang just for my case.