Import.hx for multi target project

1

Hej,

I often work on “multi projects” (like server/client) using the same classpath and I also use import.hx that I don’t want to be the same for all my builds. For now, I have to deal with some -D but I wonder if there is another solution or maybe the import.hx could be specified in the .hxml file , something like -import myImport.hx ?

2

Not sure why this is a problem. Don’t you have separate server / client packages anyway? Just put a different import.hx in each of those.

Also, import.hx is not package-based, it’s directory-based.

3

You can do this in your import.hx if you are using -D server

// import.hx
#if server
import server.*;
#end

#if client
import client.*;
#end
4

Hej Jens,

It’s not really a big problem, I have many solutions for that it’s just a question with maybe a suggestion.
I share a lot of classes that lie in the same directory.

5

Ah, so your problem is not the server / client code, it’s the code that’s shared between both? Then Mark’s solution with a define seems like the right approach.

6

Hej Mark,

Yes that is how I do for now. I found it a bit mess at the end. Let’s say, I have Server, Client and SW (service worker) in the same directory. At the end import.hxcan become dirty.
What about adding a compiler directive or option like --import myImports.hx ? Would it be difficult ? I don’t know but if not, it could be handy.

7

If there is much separation, you can also choose to separate the packages/imports a bit more. The import.hx file doesn’t have to be in the root, as far as I know.

  • src/import.hx // only global imports
  • src/server/import.hx // only server specific imports
  • src/client/import.hx // only client specific imports
8

In fact I have no separation at all. All share the same classes.
So that’s why I ask if we could have --import myImports.hx without much work ?

9

As said for now I deal with compiler directives but I think I’ll finish with 3 import files named by target let’s say clientImports.hx, serverImports.hx and swImports.hxwhich I’ll rename to import.hx with a compiler macro and back on each builds…

I wonder if it’s a lot of work of having compiler to look at the pathname given by --imports compiler option instead of a hard coded import.hx file ?

10

In fact I have no separation at all. All share the same classes.
So that’s why I ask if we could have --import myImports.hx without much work ?

How about cleaning up your code instead and introducing some separation? :stuck_out_tongue:

11

I haven’t written that my code is a mess, the client, server and sw targets share a lot of same code as DB entities, routing API and all is clear.
At root I’ve the separated Client.hx, Server.hx and SW.hx that are separated and the famous import.hx file…
I don’t want be obstinated but I just thought it could be a good idea and handy to not have hard coded import.hx file but have possibility to specify to the compiler which import.hx file to use for a specific target, that’s why I ask if it’s a so stupid idea and/or it’s a pain to implement it, to see you guys not answering my questions but instead giving me advices like that ! :smile:

Anyway, I’ll stop now, I already have solutions for my needs, as always, it was more like a suggestion for everybody who could need that, I think that it could be done easilly (maybe I’m wrong so I would be happy someone tell me just that “It’s not as simple as you say”) and that it could be handy and more “dynamic” that having a hard coded import.hx file, but If I’m the only one thinking that, I’ll not disturb with that anymore.

Have nice day guys, thanks for your interraction :slight_smile:

12

I’m wondering if you really need an import.hx to begin with if you only have three .hx files, that seems a bit overkill? Wouldn’t it be easier to just put the imports each of those files needs into the file, rather than some import.hx that’s conditionalized?

13

I have many imports from libraries for example…
So yes I use conditionnal flags in my import.hx.
So the mecanic now is to set a compiler flag (-D) and then set an #if statement in my import.hx…
And once more, I think that if it’s not much work, it could be more “dynamic” to specify an --imports options (or -D imports=myImports.hx) or whatever that makes it more dynamic/flexible.

I’ll stop now because I’ll finish to cry my tears thinking about how a suggestion like that which brings more flexibilty without much work is so discussed. I don’t want to bring pain to people :joy:

Also don’t take all that bad, I don’t speak very well english and sometimes I can express badly and seem rude. It’s not the case.

Regards

14

I don’t think you came across as rude. :slight_smile: I just think this is a bit of a XY problem and -D imports doesn’t sound like a good idea to me.

15

Also it’s good to remember that even if the new feature is easy to add unless you’re using a nightly build it wouldn’t solve your problem right away, since new releases are infrequent.

So you’ll need one of the other solution proposed here :wink:

16

And more importantly, even if a feature is easy to add, it’s still not free in terms of maintenance, documentation, etc…

17

Valentin, I also wrote upper that I already have many solutions for what I’m talking about :wink:
It was a proposal for the future, for me and the others all over the world and universe :joy: